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The  Prototype  Route  Planner  (PRP)  described  In  this  thesis  is  the  indirect  result  of  using 
object-oriented  code  to  impiement  a  routing  algorithm  for  a  tactical  communications  network.  My 


originai  intent  was  to  demonstrate  that  a  routing  algorithm  could  automate  channel  allocation, 
even  though  its  host  network  Is  constrained  by  limited  computing  power  at  each  node.  Zenith 
248's  were  to  represent  the  nodes  while  their  communications  ports  were  to  act  as  media  links. 
Although  PCs  were  readily  avaBable,  none  of  them  had  the  multiple  ports  necessary  for  a  small 
network  demonstration.  Instead,  I  chose  to  simulate  a  network  of  multiple  nodes  and  links  on  a 
single  machine.  To  validate  that  the  algorithm  works  even  with  a  damaged  network,  I  added  a  way 
to  kill  components.  I  believe  that  design  concepts  developed  for  PRP  can  be  used  to  create 
tactical  networks  from  scratch  or  to  test  how  networks  react  when  damaged. 
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\  Abstract 

The  circuits  in  a  mBitary  command  and  control  n^ork  are  expected  to  operate 
continuously  in  spite  of  changes  arxl  damage,  and  must  be  restored  in  minutes  should  they  fail. 
This  study  examines  circuit-buBding  as  a  resource  allocation  problem,  and  describes  an  approach 
to  the  decentralized  allocation  of  prioritized  circuits  in  such  a  network.  Based  on  a  saturation 
search  algorithm,  a  circuit-request  message  ripples  from  an  originating  node  through  the  network 
to  the  circuit’s  destination  tKxle,  providing  a  path  exists.  Along  the  way  the  message  retains  cost 
and  path  information  that  is  used  to  attenuate  expensive  routes  and  provide  path  information 
during  the  back-sweep  of  the  allocation  phase. 

An  object-oriented  program  written  in  Scheme  helped  capture  the  details  of  nodes,  links, 
channels,  and  circuits  in  the  network,  arxl  showed  how  these  components  would  interact  when 
guided  by  the  algorithm.  The  program  has  two  purposes.  First,  it  validates  the  concept  that  a 
common  software-based  assistant,  distributed  to  each  node,  can  aid  operators  in  the  rapid 
reconstruction  of  a  badly  damaged  network.  Secorxi,  it  provides  a  planning  aide  for  tactical 
network  designers,  who  can  use  the  program  to  model  nodes,  trunk-lines,  channels  and  circuits. 

A  tactical  network  employing  distributed  allocation  and  priority-coding  of  its  circuits, 
allows  operators  to  forgo  ^ored  restoration  plans  as  their  principal  means  of  maintaining  service. 
This  approach  offers  flexibility  and  responsiveness  despite  the  likelihood  of  multiple  outages  and 
rapid  changes,  something  that  plans  can  not  always  deliver  especially  in  time  of  war. 
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OBJECT  ORIENTED  ALLOCATION  OF  RESOURCES 
IN  A  TACTICAL  COMMUNICATIONS  NETWORK 

I.  Introduction 

The  Communications  Nodai  Control  Bement  (CNCE)  is  a  box-like  structure  the  size  of  a 
step-van  that  contains  switching  equipment  to  support  Air  Force  dedicated  communications 
channels  via  microwave,  satellite,  and  land-line  media.  Each  deployable  unit  can  be  air-dropped  or 
trucked  to  Its  field  site,  then  activated  to  serve  as  a  regional  switching  center,  supporting  data, 
voice  lines,  arxj  other  formats.  These  CNCE  "rKXjes”  permanently  link  field  commanders  to  higher 
commarxl  authority,  thereby  ensuring  combat  theater  communications  essential  for  regional 
warfare  (Warmuth  1988). 

A  typical  deployment  scenario  weaves  more  than  a  half  dozen  CNCEs  into  a 
communications  network.  Positioned  at  strategic  spots  throughout  a  tactical  theater,  they  provide 
a  dedicated  and  redundant  network  of  communications  circuits.  Associated  with  each  scenario, 
an  operations  plan  (annex  K)  details  how  communications  personnel  should  interconnect 
adjacent  stations  to  distant  command  authority,  thereby  forming  the  net.  These  links  or  trunks 
carry  the  dedicated  communications  circuits,  whfle  spare  channels  and  currently-used, 
lower-priority  channels  in  each  trunk  provide  a  vehicle  for  redundant  backup.  The  unused  trunk 
capacity  also  provides  a  means  for  communications  personnel  to  accommodate  additional  circuit 
requests. 

Problem  Background 

Depending  on  the  environment,  communications  personnel  face  several  kinds  of  resource 
allocation  problems.  The  first  deals  with  network  planning.  As  each  operations  plan 
accommodates  anticipated  circumstances,  diverse  needs,  and  last  minute  changes,  it  is  not 
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surprising  that  up  to  two  months  may  pass  before  final  acceptance  of  a  pian  by  Wing  or 
Numbered  Air  Force.  Furthermore,  during  actual  deployment  the  CNCE  network  must  be 
fine-tuned  to  reflect  new  conditions.  Technical  Controllers  presently  revamp  the  network  manueilly 
via  patch  cord  connections,  using  protocols  learned  through  war-time  experience  and  peace-time 
fficercises.  The  updates  they  make  fall  into  allocative  and  restorative  categories:  (a)  build 
dedicated  circuits  using  channels  to  link  CNCEs,  or  (b)  re-route  a  segment  of  the  circuit  around  a 
damaged  link  using  spare  or  preempted  channels  (Warmuth,  1988). 

Ironically,  the  patch  cord  feature  that  makes  a  CNCE  network  so  very  flexible  imposes  a 
labor-intensive  process  that  detracts  from  responsiveness.  The  ultimate  test  occurs  during  war, 
when  technical  controllers  as^ned  to  each  CN^  must  reconstruct  a  severely  damaged  net 
without  knowing  the  corKlition  of  the  rest  of  the  system.  They  will  be  constrained  by  a  lack  of 
global  knowledge,  as  each  CNCE  controller  knows  only  the  status  of  channels  connecting  the 
specific  CNCE  to  adjacent  CNCEs.  In  order  to  effect  repairs,  each  link's  operability  must  be 
ascertained  arxl  communicated  throughout  the  network.  Although  automatic  switching  equipment 
controls  the  dedicated  lines  once  establisi^,  it  is  the  communications  personnel  who  must 
establish  new  requests  and  fix  malfurx:tions  using  time-intensive  manual  techniques. 

Overview 

This  study  explores  traditional  algorithmic  and  constraint  propagation  techniques  with  the 
intent  of  impiementing  an  object-oriented  software  solution  for  communications  personnel  to  use 
to  quickly  establish  dedicated  circuits  in  a  CNCE  network.  In  Chapter  II,  the  problem  is  explained 
in  terms  of  an  undirected  graph,  then  the  literature  rev  lew  of  Chapter  III  covers  previous  research, 
placing  special  emphasis  on  approaches  that  work  without  global  network  knowledge.  The  design 
implementation  of  Chapter  IV  maps  out  an  object-oriented  approach  that  mirrors  the  environment, 
while  Chapter  V  assesses  the  resulting  Prototype  Route  Planner  and  projects  the  feasibility  of 
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using  a  simHariy  designed  Technical  Controiier's  Assistant  for  use  in  an  operationai  CNCE 
network. 

Scope 

Since  buOding  new  communications  circuits  reaiisticaiiy  indudes  aitemative  trade-offs, 
priorities,  maximum  hop  (path)  iength,  etc.,  this  work  focusses  on  ways  to  ailocate 
communications  channeis  in  a  pre-estabiished  network  of  trunk  lines,  given  a  request  for  new 
dedicated  circuits.  Since  a  damaged  net  la  nothing  more  than  a  pre-estabiished  communication 
chain  with  broken  links,  these  severed  links  form  a  speciai  class  of  channel  requests  that  when 
satisfied,  also  serve  network  reconstruction.  For  this  reason,  any  automated  approach  that 
allocates  channel  resources  for  new  circuits,  also  serves  the  dual  purpose  of  patching  damaged 
circuits. 

^aumotiana 

This  study  assumes  a  small  node  population,  as  no  more  than  47  CNCE  units  were 
produced  and  only  a  portion  of  these  will  be  connected  for  theater  operations.  CNCE  units  host 
modest  computing  power,  (64K  of  RAM  and  limited  permartent  storage  capacity);  hence,  this 
study  presumes  an  external  computing  source,  in  each  node,  capable  of  implementing  search 
procedures.  Lastly,  this  study  assumes  that  a  CNCE  node  can  talk  to  its  neighbor  using  the  same 
communications  iirfes  that  carry  data  irat}lity  to  contact  a  neighboring  node,  even  if  caused  by  a 
malfunction,  is  interpreted  as  destruction  of  that  node. 
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Some  prablems  can  be  resolved  by  decomposing  the  whole  into  individually  solvable 
pieces.  Ol^ect  oriented  programming  adheres  to  this  phfiosophy  in  that  it  breaks  a  system  into 
ot^ects  that  function  like  their  real-worid  counterparts,  and  in  doing  so  permits  the  programmer  to 
concentrate  on  one  well  understood  object  at  a  time  (Booch,  1987:16).  This  chapter  paves  the 
way  for  an  object  oriented  design  by  presenting  a  ONCE  network  as  a  graph  made  of  node,  link, 
arxi  channel  objects.  It  then  reviews  how  to  allocate  channels  to  a  circuit,  and  concludes  with 
manual  circuit  restoration  techniques. 

A  ONCE  tactical  communications  network  exists  to  carry  messages  from  one  destination 
to  another;  this  is  accomplished  through  a  web  of  interconnected  CNCEs  and  trunk  lines.  The 
circuits  in  a  CNCE  network  are  bi-directional;  hence  an  undirected  graph  conveniently  describes 
the  major  physical  features  of  such  a  network.  The  circular  nodes  of  an  undirected  graph 
represent  the  Communications  Nodal  Control  Bements,  while  the  links  (connecting  lines)  of  an 
urxfirected  graph  depict  the  trunks  that  carry  communications  circuits.  Throughout  this  paper  the 
term  "circuir*  refers  not  to  the  graph-theory  definition -a  series  of  links  that  begin  and  end  at  the 
same  node -but  to  a  telecommunications  connotation,  where  two  parties  talk  through  a  path  that 
does  not  double  back  on  itself.  In  graph-theory  nomenclature,  this  form  of  "circuir*  is  actuaily  a 
simple  (each  link  used  only  once),  elementary  (each  rxxfe  used  only  once),  chain  of  links 
connecting  one  node  to  another  (Christofides,  1975:4). 

Network  Reoreaentation 

Figure  1  shows  how  the  CNCEs  aixf  trunks  of  a  simple  network  appear  in  graph  form.  The 
nodes  (CNCEs)  serve  as  junctions,  terminating  the  connecting  links  (trunks)  of  the  network.  The 
links  span  only  a  single  pair  of  nodes,  and  unlike  a  node,  which  can  exist  without  links,  a  link  must 
adjoin  nodes  (typically  two  distirtct  nodes).  Although  links  carry  circuits,  there  exits  a  unit  of 
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conveyance  that  Is  more  basic  than  the  trunk.  This  property  belongs  to  channels  which  propagate 
the  message  contents  of  a  single  circuit  and  which  are  characterized  by  some  transmission  rate, 
64-kbps  for  example.  A  trunk  typically  contains  172  chanrteis  that  are  time-sequenced  (Sues, 
1988).  In  Figure  1,  a  blow-up  of  one  of  the  representative  links  shows  that  it  contains  six  channels. 
One  shortcoming  of  the  undirected  graph  representation  so  far  Is  that  it  tells  to  show  the  used  and 
unused  channels  of  a  trunk.  Normally,  trunks  contain  numerous  channels,  any  one  of  which  can 


be  allocated  to  a  circuit  to  pass  Information  between  CNCEs  (in  reality  some  channels  have  higher 
transmission  rates  than  others,  but  for  the  purpose  of  this  study,  it  is  assumed  that  all  channels 
have  Identical  throughput  and  are  Interchangeable).  The  number  of  channels  in  a  trunk  determines 
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Its  capacity.  One  could  argue  that  channels  themselves  should  be  represented  by  links,  but  this 
convention  ignores  the  trunk  as  an  entity  and  clutters  the  graph  with  numerous  parallel  lines.  For 
this  reason,  the  following  graphs  use  only  nodes  for  CNCEs  and  lines  for  trunks. 

Since  channels  have  no  pictorial  representation,  the  following  labeling  scheme  explicitly 
shows  the  capacity  of  each  link  and  affords  the  observer  a  better  idea  of  the  capacity  of  the  overall 

network.  Rrst.  let  us  describe  the  network  as  {  CNCEi . CNCEn} ,  the  set  of  CNCE  nodes  in 

the  tactical  network.  Next,  let  Unkijk  denote  a  trunk  (if  one  exists)  connecting  nodes  CNCEi  and 
CNCEj  ,  where  k  distinguishes  parallel  links  when  they  exist  Finally,  let  qjk  be  the  capacity  of 
Linkijk,  expressed  so  as  to  show  the  number  of  circuits,  by  priority,  that  the  link  can  support.  This 
last  requirement  sounds  complicated,  but  if  one  uses  vector  notation  to  display  a  sort  of 
prioritized-capacity,  an  entire  network  can'be  described  (figure  2). 

Before  proceeding  further,  one  should  note  that  if  this  were  not  a  military  network,  there 
would  be  no  need  to  represent  capacity  as  a  vector.  An  equivalent  no-priority  network  needs  only 
a  single  number  to  relate  its  capacity  since  there  are  only  allocated  aruf  unallocated  channels. 
Indeed  most  graphs,  including  those  in  the  next  chapter,  use  this  convention. 

The  CNCE  tactical  network  recognizes  a  circuit  hierarchy  based  on  priority.  This  study 
arbitrarily  employs  three  priorities:  A,  the  highest;  B,  an  intermediate;  and  C.  the  lowest  priority. 
These  correspond  to  priorities  in  a  tactical  network.  A  circuit’s  importance  determines  its  priority, 
arxf  when  carried  via  the  network,  all  participating  channels  assume  the  same  priority.  Prior  to 
allocation,  a  channel  has  no  status  and  is  considered  spare.  Looking  at  all  the  channels  in  a  trunk, 
one  can  summarize  their  use  and  capacity  with  the  vector  [ABC  spare] .  This  four-place  vector 
shows  the  number  of  channels  allocated  to  A,  B,  or  C  priority  circuits  as  well  as  the  number  of 
channels  in  spare  status,  in  addition  to  displa^ng  the  present  state  of  a  trunk's  channels,  this 
vector  provides  additional  information  about  its  abRity  to  support  more  circuits.  For  example  in 
figure  2,  consider  qzsi  *[0213]  which  says  that  Unkzsi  carries  no  A-priority  circuits,  two 
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B-priority  circuits,  one  C-priority  circuit,  and  ttiree  spare  channeis  for  a  totai  of  six  channeis,  three 
of  which  are  ailocated. 


Figure  2.  Example  Network  Graphical  Representation 


AJIocatlon  ConsMeratlons 

A  communications  person  called  a  technical  controller  could  use  this  information  to 
allocate  a  channel  to  a  new  circuit.  Given  a  B-priority  circuit  request,  the  technical  controller  could 
pick  any  of  the  three  spares  or  the  C-priority  channel  to  dedicate  to  the  new  circuit.  The  technical 
controlier  can  not  preempt  B-priority  channeis  since  they  have  the  same  priority  as  the  request. 
Likewise,  if  there  were  any  A-priority  channels,  fh9  technical  controller  could  not  preempt  a  higher 
priority  channel  for  a  lower  priority  request. 
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The  same  vector  notation  can  be  used  to  count  the  cost  of  establishing  a  new  circuit. 
Intuitively,  one  can  see  that  picking  a  spare  channel  in  the  above  example  wilf  not  disrupt  any 
active  circuits.  But  if  the  C-priority  channel  is  preempted  to  flU  the  new  request,  the  n^ork  suffers 
the  penalty  of  a  broken  circuit  One  way  to  measure  the  cost  of  horxjring  a  circuit  request  is  to 
think  of  it  in  terms  of  a  cost  vector.  Let  cijk  >  [A  B  C  spare] ,  represent  the  vector  cost  of  using  a 
channel  in  linki]k  ■  The  value  of  ajk  depends  on  the  precedence  of  the  circuit  using  the 
channel-resource.  If  unallocated,  the  channel  costs  one  spare,  or  [0  0  0 1] ,  to  use.  If  previously 
allocated,  the  priority  of  the  owning  circuit  dictates  the  cost  of  preempting  the  channel  (for 
example,  a  top  priority  channel  costs  qk  >{1000}  to  use).  With  this  framework,  one  can 
construct  a  circuit  or  path  which  connects  an  origin-node  to  a  destination-node  via  a  route  of 
alternating  links  and  support  nodes,  whose  total  cost  is  the  sum  of  all  the  qks  produced  along  the 
way.  Thus  a  circuit’s  cost  might  look  like  [0013],  which  says  that  one  C-channei  and  three 
spare  channels  are  needed  to  build  the  proposed  circuit. 

The  technical  controller's  task  is  to  route  a  circuit  from  an  originating  CNCE,  through  the 
network,  terminating  at  the  destination,  without  exceeding  trunk  capacity,  at  minimum  cost,  and 
without  knowing  in  advance  current  channel  allocations.  Prepared  backup  plans  simplify  this  task 
for  the  technical  controller.  If  a  circuit  goes  bad,  the  controller  switches  to  the  backup  circuit,  and 
if  time  permits,  isolates  the  bad  segmerit  for  later  repair.  If  the  fault  is  isolated  to  a  bad  channel, 
swapping  it  with  a  spare  channel  rejuvenates  the  now  inactive  circuit  for  subsequent  backup  use. 
This  method  of  circuit  maintenance  works  well  for  repairing  infrequent  malfunctions,  but  a  different 
mode  of  operation  prevails  during  massive  outages.  In  the  event  of  significant  damage,  technical 
controllers  restore  service  based  on  priority.  First  they  fix  high  priority  circuits  using  available 
backups,  but  if  there  are  none,  they  reinstate  service  at  the  expense  of  lower  priority  circuits. 
Depending  on  the  circumstances,  the  repair  process  can  quickly  exceed  the  limits  of  a  backup 
plan.  For  this  reason  the  next  chapter  considers  algorithmic  approaches  to  alleviate  potential 
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problems  during  massive  outages,  whie  the  chapter  after  it  shows  how  to  apply  object  oriented 
programing  to  model  the  nodes,  links,  and  channels  just  discussed. 
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The  intent  of  this  iiterature  tWiaH  is  to  find  a  suitable  algorithm  that  can  be  used  to  find 
circuit  routes  within  a  damaged  CNCE  n^work.  As  much  work  has  aiready  been  done  on  routing 
and  search  algorithms,  it  Is  only  logical  to  assume  that  some  previously  applied  solution  can  be 
adapted  to  work  in  the  tactical  communications  environment  Routing  and  search  algorithms  are 
found  imbedded  in  many  areas,  not  just  in-communications,  therefore  this  review  analyzes: 
a)  conventionai  algorithms,  b)  future  communications  protocols,  and  c)  constraint-based 
approaches.  The  key  concepts  used  in  each  methodology  can  be  applied  to  the  design  of  a 
distributive  allocation  algorithm  for  a  CNCE  network. 

Conventional  Algorithms 

Operations  research  books  and  journals  abound  with  discussions  of  conventional 
algorithms  used  to  optimize  resources.  They  afford  a  good  starting  point  for  CNCE  network 
channel  allocation,  as  many  such  algorithms  were  originally  designed  for  computer  optimization  of 
resources  in  a  network.  Three  algorithms  In  particidar-the  maximum  flow  algorithm,  the  minimum 
cost  flow  algorithm,  and  the  shortest  path  algorithm -share  linear  programing  as  a  common 
ancestor,  and  offer  valuable  Insight  into  the  CNCE  network  problem.  With  each  of  these 
algorithms,  be  aware  that  they  assume  a  network  has  a  single  source  and  a  single  sink.  When 
comparing  CNCE  features  to  these  algorithms,  think  of  a  circuit’s  originating  node  as  its  source, 
the  destination  node  as  its  sink,  and  the  circuit  as  needing  one  channel  resource  every  time  it 
advances  from  one  node  to  the  next. 

Linear  Programming.  At  first  glance,  constructing  a  network  made  up  of  CNCEs 


appears  to  be  a  task  best  done  using  operations  research  techniques.  If  the  goal  is  to  maximize 
communications  throughput,  a  linear  programmkig  approach  wiU  maximize  the  flow  out  of  a 
source  node  (or  the  flow  into  a  sink  node),  given  the  capacity  of  each  arc  connecting  the  network. 


Although  a  d^afled  explanation  «(ceeds  the  scope  of  this  section,  a  quick  look  at  the  variables  in 
the  linear  programming  model  shows  a  parallel  to  other  algorithmic  approaches.  The  ot^ect  of 
linear  programming  is  to  choose  values  of  independent  variables  so  that  they  maximize  or 
minimize  some  overall  objective  functioa  Constraints  limit  each  variable’s  range  of  values.  A  linear 
programming  model  proceeds  step-wise,  improving  the  objective  until  reaching  an  optimum  or 
infeasible  solution.  But  one  necessary  condition  for  linear  programming  is  total  knowledge  of  the 
network  status  before  optimization.  Even  vyhen  given  this  Information,  the  full  power  of  linear 
programming  is  not  necessary  for  efficient  resource  allocation. 

Maximum  now  Algorithm.  Markland  demonstrates  an  intuitive  and  efficient  method  of 
network  maximization  that  Is  simpler  than  a  linear  program.  Whereas  before  qijk  indicated  the 
capacity  of  a  single  Uok.  Markland  uses  the  symbol  c*i|  to  represent  the  capacity  for  flow  in  a 
complete  path,  from  nodes  I  to  j .  The  asterisk  derates  optimality  since  the  path  as  a  whole  can 
carry  only  as  much  as  its  most  restrictive  segment  wiii  permit. 

1 .  Rnd  a  path  from  source  to  sink  with  positive  (low  capacity  (each  path  segment  must 
support  the  conveyance  of  at  least  one  unit  of  flow  from  source  to  sink.  Sink  to  source 
flow  is  negative).  Obviously,  If  none  exists,  the  net  flows  already  assigned  constitute  a 
maximal  flow  pattern. 

2.  SMrch  this  path  for  the  branch  with  the  smallest  flow  capacity.  Denote  this  capacity  as 
c*i{ ,  and  increase  the  flow  in  this  path  by  c*ij . 

3.  Decrease  by  c*  j  the  flow  capacity  of  each  branch  in  the  selected  path. 

4.  Increase  by  c*i] ,  in  the  opposite  direction,  the  flow  capacity  of  each  branch  in  the 
selected  path. 

5.  Return  to  step  1  and  repeat  the  procedure  outlined  in  steps  2, 3,  and  4  until  no  paths 
with  positive  flow  capacity  remain. 

6.  Compute  the  net  flow  in  all  branches  for  which  flow(s)  have  been  assigned  in  both  direc¬ 
tions  (Markland  1983:388). 

The  above  method  optimizes  a  network,  but  only  after  an  exhaustive  search  of  all  paths, 
from  source  to  sink,  tails  to  reveal  unused  capacity.  Cteariy,  If  the  maximum  capacity  of  a  network 
were  known  ahead  of  time,  one  could  stop  searchir)g  when  the  algorithm's  new-found  capacity 
equals  the  theoretical  maximum.  The  Max  Row-  Mki  Cut  Theorem  conveniently  achieves  just  that: 


11 


If,  for  any  network,  we  find  the  cut  value  for  each  of  the  finite  number  of  cuts  that  can  be 
made  in  the  network,  then  the  smallest  total  capacity  (cut  value)  is  equal  to  the  maximum 
flow  ki  the  network  (MarMaixJ,  1983:392). 

Thus,  one  can  maximize  flow  in  a  CNCE  corrunuflcations  network,  with  a  single  source  and  sink, 
using  the  above  algorithm,  given  global  knowledge  of  node  capacity  and  arc 
assignments -making  It  extremely  useful  for  operations  planning-with  the  understanding  that  it 
will  not  necessarily  find  the  shortest  path  but  wflt  firxl  the  maximum  flow. 

Minimum  Coat  How  Algorithm.  The  minimum  cost  flow  algorithm  appears  similar  to 
the  maximum  flow  algorithm,  yet  It  adds  the  constraint  of  finding  the  shortest  avaOabie  path  within 
the  capacity  confines  of  the  network.  This  algorithm  accurately  describes  the  CNCE  network 
channel  allocation  process  with  the  caveat  that  k  does  not  implement  preemption  of  already 
assigned  channels.  In  the  following  equations  s  represents  a  single  source  node,  t  a  single  sink 
node,  I  and  j  intermediate  nodes,  fij  Is  the  arc  flow  from  node  i  to  node  j ,  Cj  is  the  cost  of 

j 

traveling  the  arc  between  nodes  i  atxi  j ,  and  qij  is  the  capacity  of  the  arc  connecting  nodes  i 
arxi  I .  The  relation 

^  (ftj-fit)  =  -V 

j 

signifies  that  the  arcs  connected  directly  to  the  source  must  absorb  the  source’s  output,  v . 

^  (fij  -  fji)  =  0  (for  all  i  ^  s,  i  ^  t) 

I 

Likewise 

represents  the  flow  discharged  by  each  arc  into  the  sink.  The  reiatlcn 

0  <  fij  <  qij 

is  the  law  of  coraervation  that  says  that  the  net  flow  out  of  (in  to)  any  node  that  is  not  a  source  or 
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sink  is  zero,  and 


min  y~  Qj  fij 

(«.j) 

relates  that  for  ail  intermediate  nodes,  the  flow  through  an  arc  must  be  positive  and  must  not 

exceed  the  arc’s  capacity.  The  goal  is  to  minimize  the  cost  as  shown  by 

subject  to  the  capacity  constraints  of  the  arcs  and  the  volume  of  flow  from  the  source.  This  can  be 

accomplished  by  summing  the  cost-quantity  products  for  every  arc  in  the  network.  Keep  in  mind 

that  the  qs  are  integers  and  in  a  ONCE  network,  would  ail  cost  the  same. 

The  minimum  cost  flow  algorithm  first  serxls  as  many  units  from  s  (source)  to  t  (sink) 
that  Incur  a  total  cost  of  0  each  for  the  entire  journey  from  s  to  t .  Next,  the  minimum 
cost  flow  algorithm  sends  as  many  units  as  possible  from  s  to  t  that  incur  a  total  in¬ 
cremental  cost  of  1  each  for  the  endrejoum^fixxn  s  to  t ,  etc.  The  algorithm  stops 
when  a  total  of  v  units  have  been>sent  from  s  to  t ,  or  when  no  more  units  can  be  sent 
from  s  to  t ,  whichever  happens  first  (Minieka,  1978:107). 

To  keep  track  of  the  incremental  or  augmenting  costs  during  the  algorithm,  each  node 
owns  a  cost  counter  that  tracks  the  cost  of  flow  In  the  forward  direction  and  flow  in  the  reverse 
direction  (reverse  flow  facilitates  the  augmenting  process  without  exceeding  branch  capacity 
constraints).  If  two  adjacent  nodes  have  different  cost  counter  values,  their  difference  represents 
the  cost  of  flow  between  the  rxxles,  or  cij. 

A  summary  of  the  minimum  cost  flow  algorithm  explained  by  Mineka  proceeds  as  follows: 

1 .  Initialize  the  flow  of  each  arc  to  zero  and  set  the  cost  counter  of  every  node  to  0. 

2.  Decide  which  arcs  can  have  flow  changes  by  examining  the  cost  potential  across  the 
arc,  Its  capacity,  and  those  arcs  already  carrying  flow. 

3.  Use  the  max  flow  algorithm  to  increment  each  cost  counter  and  to  find  each  path  re¬ 
quest  If  there  is  a  path  for  every  unit  of  source  flow,  stop  as  you  have  the  lowest  cost 
using  those  paths,  if  not  an  requests  can  be  honored  proceed  to  step  4. 

4.  Increase  the  price  of  payment  to  complete  the  path,  do  not  consider  those  arcs  with  full 
capacity,  and  return  to  step  2. 
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The  algorithm  finds  a  path  for  every  source  untt  or  untl  the  network  is  saturated.  This  approach 
would  work  well  for  a  n^work  overrun  by  new  circuit  requests  as  it  the  mo^  circuits  through 
using  the  shortest  distances.  The  algorithm  is  not  adapted  for  priorities  however. 

Dl|k«lra  Shortet  Path  Atqoftthm.  DQkstra’s  Shortest  path  algorithm  uses  temporary 
and  permanent  labels  to  determine  the  shortest  path  In  a  network.  The  algorithm  Is  as  follows; 

1 .  A  permanent  label  of  zero  is  assigned  to  the  source  node.  All  other  nodes  are  assigned 
temporary  labels  that  are  set  equal  to  the  direct  distances  from  the  source  node  to  the 
nodes  being  examined.  If  any  node  cannot  be  reached  directly  from  the  source  node  it 
is  assigned  a  temporary  label  of  -r-infintty. 

2.  All  of  the  nodes  having  temporary  labeis  are  examined  and  the  node  having  the  mini¬ 

mum  of  the  temporary  labels  is  selected  and  declared  permanent.  If  there  are  ties  be¬ 
tween  temporary  lab^  break  the  tie  arbitrarly. 

3.  Suppose  that  node  T  has  been  assigned  a  permanent  label  most  recently.  The  remain¬ 
ing  nodes  with  temporary  labels  are  wcamined,  by  comparing,  one  at  a  time,  the  tem¬ 
porary  label  of  each  node  to  the  sum  of  the  permanent  label  of  node  T  and  the  direct 
distance  from  node  T  to  the  node  being  examined.  The  minimum  of  these  two  distan¬ 
ces  is  assigned  as  the  new  temporary  label  for  that  node.  Note  that  if  the  old  tem¬ 
porary  label  for  the  node  being  examined  is  stBI  minimal,  then  it  will  remain  unchanged 
during  this  step. 

4.  Now  select  the  minimum  of  the  temporary  labels  and  declare  it  permanent.  If  there  are 
ties,  select  one,  but  only  one.  and  declare  it  permanent.  If  the  node  just  declared  per¬ 
manent  is  the  sink  node,  the  algorithm  terminates  and  the  shortest  route  has  been 
determined.  Otherwise  return  to  Step  3  (Markland  1983:393). 

After  the  algorithm  terminates,  the  shortest  path  is  identified  by  retracing  the  path 
backward  from  the  sink  node  to  the  source  node,  selecting  the  nodes  that  were  permanently 
labeled  at  each  step.  Although  the  shortest  route  algorithm  wW  find  the  optimum  route  in  a 
communication  network  when  each  link  is  assigrted  a  cost  or  path  equal  to  one,  it  does  require 
global  knowledge  at  steps  three  and  four,  to  decide  which  of  the  permanent  arxl  temporary  nodes 
to  pick  for  subsequent  Inspection. 


14 


The  newest  Air  Force  switching  n^work,  the  digital  patch  and  access  system  PPAS), 
shares  many  simlarities  with  a  ONCE  tactical  communications  network.  As  in  the  CNCE  model, 
the  DP  AS  nodes  serve  as  iunctions  for  channels.  In  addition,  the  DP  AS  network  control  system 
PNCS)  adds  a  control  hierarchy  to  maintain  the  net  Just  as  technical  controllers  in  a  CNCE 
network  Isolate  bad  circuits  and  activate  backups  on  a  tactical  level,  the  DNCS  will  accomplish  the 
same  function  automatically  on  a  strategic  level  tlvor^h  the  use  of  automated  test  equipment, 
digital  switching  networks  and  computers.  The  first  stage  of  DPAS  implementation  requires 
manual  system  control  via  "electronic  patch  cords",  whie  later  plans  call  for  an  automatic  mode, 
essentially  freeing  the  technical  controiler  for  other  work  (Computer  Sciences  Corporation 
1988:3-1).  As  the  DNCS  provides  system  "smarts",  it  must  accomplish  the  following; 

•  Respond  to  the  arrival  of  control  messages 

•  Sense  failures 

e  Find  routes 

e  Connect  circuits  via  new  routes,  preempting  other  circuits  as  necessary 

•  Release  all  segments  of  failed  or  preempted  circuits  to  spare  status,  thus  providing  net¬ 
work  resources  to  support  attempts  to  restore  teiled  or  preempted  circuits 

e  Cancel  connection  attempts  if  they  cannot  be  completed  so  as  to  prevent  partial  circuits 
from  remaining  up  -  . 

•  Confirm  all  connections  and  releases  and  document  them  in  link  fill  tables  that  form  a  real¬ 
time  distributed  connecUvity  data  base  (Computer  Sciences  Corporation,  1988:7-9) 

The  Technical  Controller  in  a  CNCE  network  currently  accomplishes  all  the  above  duties. 
The  intent  of  this  study  is  to  look  at  ways  to  help  the  controller  with  route  planning,  in  this  respect, 
a  CNCE  route  planning  algorithm  can  benefit  from  DNCS  algorithm  research.  Three  algorithms, 
discussed  in  the  following  paragraphs,  have  been  considered  for  DNCS  route  planning. 

Algorithms  1  and  3  show  considetabie  promise;  Algorithm  2  has  been  eliminated  due  to  the  high 
message  traffic  it  generated.  Algorithm  1  is  sknlar  to  Ludwig  and  Roy’s  cail-routing  algorithm 
(Ludwig  and  Roy,  1977:1353),  whIe  Algorithm  3  is  an  adaptation  of  the  shortest  path  algorithm. 


Algorithm  1.  The  destination  node.  In  the  DNCS  version  of  Algorithm  1 .  initiates  a 
SEARCH  message  whenever  It  needs  to  find  a  route  to  the  origin  node.  In  doing  so  it  sends  the 
SEARCH  message  to  all  adjacent  nodes  that  attach  via  spare  or  lower  priority  channels,  in  other 
words.  If  two  nodes  connect  only  through  fully  committed,  top  priority  channels,  aixi  the  SEARCH 
message  seeks  out  a  low  priority  route,  then  the  SEARCH  message  wfll  never  transit  the  top 
priority  link  as  It  can  not  bump  a  chann^  dr  find  a  spare.  As  the  SEARCH  messages  filter  through 
the  network,  they  collect  costs  based  on  hop-iengtit  and  priority.  EventuaUy  (if  a  path  exists),  a 
message  reaches  the  source  rxxle,  where  It  starts  a  timer  and  waits  for  other  SEARCH  messages 
to  arrive.  As  the  messages  arrive,  the  source  node  orders  the  routes  by  increasing  cost,  displaying 
the  results  for  the  controller  to  act  on.  After  the  time  expires,  the  source  node  uses  the  lowest  cost 
or  most  appropriate  route  information  to  retrace  its  steps,  teiiing  the  supporting  nodes  to  commit 
resources  for  the  chosen  path.  Thus,  each  node  stores  only  information  about  itself,  its  neighbors, 
and  the  status  of  the  links  leading  to  its  neighbor  nodes.  In  addition,  each  node  maintains  a 
search-in-progress  table  that  tracks  a  fixed  number  of  lowest-cost  requests  (Computer  Sciences 
Corporation  1988:7-11). 

Algorithm  3.  Algorithm  3  uses  a  form  of  the  shortest  path  algorithm  discussed  earlier. 
The  rTKxlified  version  works  around  the  global  knowledge  requirement  by  storing  link  allocation 
information  in  a  table  for  every  link  in  the  network  (Computer  Sciences  Corporation,  1 988:7-1 4). 
CHANGE  messages,  dated  with  time-stamps,  update  each  node’s  table  whenever  a  channel 
status  changes.  Due  to  propagation  delays,  one  part  of  the  network  may  not  know  the  status  of 
another  part  of  the  network.  By  examining  each  CHANGE  message  time  stamp  and  rejecting  old 
information  for  new,  the  node  learns  about  the  global  status  of  link  assignment. 

Between  Algorithm  1  and  Algorithm  3,  the  first  appears  the  better  suited  for  CNCE 
impiementatioa  The  algorithm's  simple  design  and  limited  need  for  internal  storage  of 
intermediate  results  make  it  particularly  attractive  in  the  memory-constrained  environment  of  a 
CNCE  network.  Algorithm  1  passes  fewer  messages  and  thereby  places  less  of  a  demand  on  the 
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network.  On  Vns  other  hand,  Algorithm  3  wM  always  optimize  a  route,  but  the  end  does  not  justify 
the  means-from  a  practical  vlewpoint.'a  Vtorking  circuit  Is  all  that  is  needed.  One  common  theme 
is  that  both  algorithms  use  the  same  structure  to  describe  the  channel  allocation  process 
discussed  next 

DNCS  Link  Coating  Scheme.  Computer  Sciences  Corporation  outlines  a  way  to 
determine  link  cost  in  a  preemptive  environment,  widt  obvious  implications  for  a  CNCE  network.  In 
a  military  network  employing  circuit  restoration  priorities,  the  “best  route"  corresponds  to  the 
lowest  cost  route,  where  the  route  cost  parameter  measures  both  the  efficient  use  of  network 
resources  and  the  number  arvi  importance  of  subscribers  who  may  be  denied  service  if  it 


becomes  necessary  to  preempt  a  channel  to  restore  a  higher  priority  circuit  (Computer  Sciences 
Corporation,  1988:7-15).  Thus,  the  costing  scheme  is  designed  to  serve  the  maximum  number  of 
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high  priority  users.  Potentially  valuable  as  a  CNCE  protocol,  the  DNCS  costing  scheme  formalizes 
the  priority,  capacity,  and  avaflabitity  of  linRs  that  connect  two  adjacent  nodes,  or  digroups  (digital 
groups).  Consider  a  north  and  south  node  connected  by  a  link  made  of  many  channels  (Figure  3). 
Each  channel  owns  a  priority  attribute  (arbitrarily  A.  B.  or  C  for  this  study)  if  it  participates  in  a 
dedicated  circuit;  otherwise  an  unassigned  channel  retains  its  spare  status.  A  link  allocation  vector 
describes  the  overall  channel  composition  (the  same  as  qj  in  the  previous  chapter).  Ordered  by 
decreasing  priority,  the  allocation  vector  contains  the  number  of  channels  assigned  to  each 
priority,  tis  well  as  those  In  spare  status.  For  example,  the  number  5  signifies  five  channels  hold 
the  highest  priority  while  the  last  number,  3 ,  represents  three  spares.  By  modifying  this  format 
slightly,  one  can  easily  build  a  preemptive  circuit  vector  that  shows,  by  priority,  the  number  of 
channels  capable  of  fulfilling  a  request.  Rrst,  discard  the  number  of  top-priority  channels  since 
they  can  not  be  preempted  even  by  another  A-priority  request.  Then  replace  each  allocation 
vector  component  with  the  cumulative  sums  of  ail  lower-priority  channels. 

The  preemptive  vector  quickly  identifies  the  quantity  of  channels  available  to  any  priority 
circuit  The  vector,  however,  does  not  specify  which  resource  will  be  used  first  (spare  versus  lower 
priority).  Thus  the  algorithm  designer  faces  a  preemption  choice,  pitting  cost  against  the  value  of 
an  established  connection. 

Constraint-Baaed  Approaches 

This  study's  final  source  of  algorithmic  information  comes  from  specific  applications 
within  the  artificial  intelligence  community.  The  applications  themselves  include  pattern 
recognition  and  distributive  problem-solving,  but  more  importantly,  the  tools  used  to  solve  these 
problems  can  also  be  applied  to  allocating  channels  in  a  tactical  communications  network.  Rather 
than  apply  constraints  to  centrally  collected  data,  as  in  linear  programming,  constraint 
propagation  Instead  nters  data-rtodes  through  a  sieve  made  up  of  constraints  that  capture  some 
aspect  of  the  problem  domain.  The  constraints  eliminate  a  portion  of  the  solution  space  that 
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contains  infeasible  soiutions,  thereby  reducing  the  time  needed  to  search  the  remaining  feasible 
space  for  a  proper  solution.  Constraint  problem-solving  uses  a  two-step  process.  First,  analyze 
the  problem  domain  to  determine  what  the  constraints  are.  Second,  solve  the  problem  by 
applying  a  constraint  satisfaction  algorithm  that  effectively  uses  the  constraints  from  the  first  step 
to  control  the  search  (Rich,  1983:351). 

Before  going  into  more  detail  about  identifying  constraints  and  how  to  control  search,  a 
look  into  the  early  uses  of  constraints  will  serve  as  a  springboard  for  later  discussion.  Although  not 
the  first  to  use  constraint  propagation.  Stallman  and  Sussman  used  this  term  as  well  as 
dependency  directed  backtracking  to  describe  conditions  in  a  computer-aided  circuit  analysis 
expert  system  called  EL,  which  was  written  in  a  problem-solving  rule-based  language  called  ARS. 
In  the  EL  contexL  constraint  propagation  refers  to  symbolic,  linear  relations  attributed  to  certain 
aspects  of  electrical  components  (Stallman  and  Sussman,  1977:138).  It  takes  the  form  of  demons 
that  add  constrained  assertion  values  to  the  data  base  whenever  their  antecedent  conditions  are 
met.  These  changes  provoke  other  demons  to  fire  until  no  new  assertions  are  added,  or  a 
contradiction  appears.  The  term  dependency  directed  backtracking  describes  how  the  system 
deals  with  contradictions. 

The  antecedents  of  the  contradictory  facts  are  scanned  to  find  which  nonlinear  device 
state  guesses  (more  generally,  the  backtrackable  choicepoints)  are  relevant;  ARS  never 
tries  that  combination  of  guesses  again.  A  short  list  of  relevant  choicepoints  eliminates 
from  consideration  a  large  number  of  combinations  of  answers  to  all  the  other  (irrelevant) 
choices  (Stallman  and  Sussman,  1977:138). 

The  importance  here  is  that  small  changes  in  the  value  of  a  parameter  do  not  necessitate  update 
of  the  entire  data  base,  and  when  conflict  does  arise,  major  portions  of  the  search  space  do  not 
have  to  be  re-examined. 

Waite  Algorithm.  Constraints  have  been  applied  to  other  areas  in  other  ways.  Waltz 
used  constraint  satisfaction  to  deal  with  the  problem  of  perception.  His  algorithm  labels  comers  in 
a  blocks  world  scene  and  deduces  from  these  constraints  the  nature  of  objects  (Rich,  1 983:351 ). 
Rich  summarizes  the  comer  finding  process  of  the  algorithm: 
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1 .  Find  the  lines  at  the  scene/boundary  border  and  label  them.  These  lines  can  be  found 
by  finding  an  outline  such  that  no  vertices  are  outside  ft. 

2.  Number  the  vertices  of  the  figure  to  be  analyzed.  These  numbers  correspond  to  the 
order  in  which  the  vertices  will  be  visited  during  the  labeling  process.  To  decide  on  a 
numbering,  do  the  foliowing: 

1.  Start  at  a  vertex  at  the  boundary  of  the  figure.  Since  boundary  lines  are  known, 
the  vertices  involving  them  are  more  highly  constrained  than  are  interior  ones. 

2.  Move  from  the  vertex  along  the  boundary  to  an  adjacent  unnumbered  vertex 
and  continue  until  all  boundary  vertices  have  been  numbered. 

3.  Number  Interior  vertices  by  moving  from  a  numbered  vertex  to  some  adjacent 
unnumbered  one.  By  always  labeling  a  vertex  next  to  one  that  has  already 
been  labeled,  meximum  use  can  be  made  of  the  constraints. 

3.  Visit  each  vertex  V  in  order  and  attempt  to  label  it  by  doing  the  following: 

1 .  Using  the  set  of  [eighteen]  possible  vertex  labelings ...  attach  to  V  a  list  of  its 
possible  labelings. 

2.  See  whether  some  of  these  labelings  can  be  eliminated  on  the  basis  of  local 
constraints.  To  do  this,  ttcamine  each  vertex  A  that  is  adjacent  to  V  and  that 
has  already  been  visited.  Check  to  see  that  for  each  proposed  labeling  for  V , 
there  is  a  way  to  label  the  line  between  V  arxl  A  in  such  a  way  that  at  least 
one  of  the  labelings  listed  for  A  is  stnt  possible.  Eliminate  from  NTs  list  any 
labeling  for  which  this  is  rx)t  the  case. 

3.  Use  the  set  of  labelings  just  attached  to  V  to  constrain  the  iabelings  at  vertices 
adjacent  to  V .  For  each  vertex  A  that  was  visited  In  the  last  step,  do  the  fol¬ 
lowing: 

1 .  Biminate  ail  labelings  of  A  that  are  not  consistent  with  at  least  one 
labeling  of  V . 

2.  If  any  labeiings^ere  eliminated,  continue  constraint  propagation  by  ex¬ 
amining  the  vertices  adjacent  to  A  and  checking  for  consistency  with 
the  restricted  set  of  labelings  now  attached  to  A. 

3.  Continue  to  propagate  until  there  are  no  adjacent  labeled  vertices  or 
until  there  is  no  change  made  to  the  existing  set  of  labelings  (Rich, 
1983:357). 

Conatralnt  Satisfaction.  Constraint  satisfriction  differs  from  the  previous  constraint 
propagation  example  in  that  satisfaction  uses  a  list  of  labels  to  annotate  a  set  of  constraints, 
whereas  propagation  conveys  an  explicit  linear  relationship.  The  advantage  to  Waltz’s  algorithm  is 
that  It  guarantees  a  correct  figure  labeling  If  one  exists.  Furthermore,  its  utflity  increases  as  the 
ratio  of  constraints  to  nodes  Increases  (Rich,  1983:358).  Davis  notes  that  the  Waltz  algorithm  is 
always  complete  frx  a  single  constraint,  but  that  it  is  not  always  complete  for  a  set  of  constraints 
pavis,  1987:290). 
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Even  though  differences  e)dst  b^ween  label  and  linear  versions  of  constraint  propagation, 
Davis  concludes  that  they  share  valuable  corntnon  properties: 

•  Simple,  easy  to  update  control  structures 

•  Yield  partial  answers  undertime  limitations 

•  Easly  Implemented  in  parallel 

•  Well  sutted  to  Incremental  systems 

•  Work  well  for  localized  Information  (Davis,  1977:283) 

The  upshot  of  these  slmlarities  Is  that  the  ONCE  nMwork  problem  falls  into  a  class  of  constraint 
labeling  problems  that  can  be  solved  efficiently.  Davis  likens  a  constraint  label  system  of 
inequalities  to  the  solution  of  a  shortest  path  problem  on  weighted  graphs,  and  finds  that: 

The  Waltz  algorithm  is  complete  for  the  whole  Inference  process  (assimilation  together 

with  query  answering).  Moreover,  if  we  perform  refinenient  in  the  proper  order,  then,  for 

consikent  sets  of  constraints,  the  system  reaches  quiescence  in  time  0(n^  (Davis, 

1987:304). 

By  assimaation,  Davis  means  the  process  of  finding  the  path  from  the  originator  to  the 
destination.  Query  answering  is  the  return  of  the  optimal  answer  from  the  destination  to  the 
originator.  Not  surprisingly,  this  particular  instance  of  constraint  propagation  captures  elements  of 
the  Minimum  Cost  Row  algorithm  presented  earlier.  The  Waltz  algorithm  merely  details  how  to  go 
about  building  the  path  arxf  how  to  pick  the  best  path  during  reTinement. 

MuMstage  Negotiation  in  Distributed  Planning.  Conry,  Meyer,  and  Lesser  describe  a 
multistage  negotiation  paradigm  for  planning  in  a  distributed  environment  with  decentralized 
control  arKi  limited  intercommunication  (Conry,  etal..  1986:1).  The  motivation  for  their  work  is  the 
same  as  for  this  paper,  in  other  words,  to  provide  for  the  control  of  a  complex  communications 
system,  without  relying  on  a  central  planning  function.  They  summarize  the  problem  as  follows: 

•  Goals  are  autortomously  generated  at  ixxJes  in  the  system 

•  The  same  system  goal  may  be  gerterated  at  more  than  one  node,  independently. 

•  Knowledge  about  local  resource  avalablity  and  potential  goal  interactions  at  each  node 
differs  from  that  at  other  nodes. 

•  Goal  satistaction  in  general  requires  nonlocal  resources. 
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•  The  planning  probiam  being  addressed  b.  In  genecal.  overconstrained.  A  choice  to  satis¬ 
fy  some  goals  may  preclude  the  satisfaction  of  others,  so  choice  heuristics  are  necessary. 


•  Goals  are  prioritized,  but  this  does  not  imply  a  total  ordering  with  respect  to  priority  (Conry, 
1986:7). 

The  authors  employ  a  form  of  negotiation,  simlar  to  contract  bidding,  to  communicate 
primal  needs.  Using  a  carefully  crafted  arbitration  process  known  as  multistage  negotiation,  the 
"agents"  responsible  for  proposing  and  communicating  goals  progressively  learn  how  their 
demands  will  affect  adjacent  nodes  (and  ultimately  the  success  or  failure  of  the  proposed  goal)  as 
other  agents  distribute  information  through  the  network.  The  messages  that  an  agent  receives  fall 
into  one  of  two  categories:  the  first  is  a  request  to  discover  how  other  nodes  will  commit 
themselves;  the  other  is  feedback  from  nodes  responding  to  a  commitment  request. 

This  form  of  information  exchange  enables  nodes  to  determine  locally  if  a  goal  is  a  good 
one  or  contains  negative  information  reflecting  r>orv4ocal  resource  conflict  (Conry,  etal..  1986:10). 
The  information  exchange  continues  untl  no  more  changes  take  place,  or  alternatively,  until  a 
pre-determlned  time  limit  large  enough  to  accommodate  ail  expected  transactions  expires.  In 
general,  a  node  first  propagates  p-goals  (primary  goals)  to  neighbor  nodes.  In  response  they 
generate  s-goals  (secondary  goals)  to  help  out  their  neighbor.  Should  the  neighbor  not  be  able  to 
help,  the  neighbor  passes  the  conflict  information  on  to  others  who  in  turn  reconsider  their 
s-goals.  The  negotiation-sequence  is  summarized  below. 

1 .  Each  node  examines  its  own  p-goais,  making  a  tentative  commitment  to  the  highest 
rated  set  of  locally  feasible  plan  fragments  for  p-goals  (s-goals  are  not  considered  at 
this  point  because  some  other  agent  has  correspondiiig  pigoals). 

2.  Each  node  requests  that  other  agents  attempt  to  confirm  a  plan  choice  consistent  with 
Its  commitment  Note  that  an  agent  need  orily  communicate  with  agents  who  can 
provide  input  relevant  to  this  tentative  commitment 

3.  A  node  examines  Rs  fcicomi^  queue  for  communications  from  other  nodes.  Requests 
for  confirmation  of  other  agents'  tentative  commitments  are  handled  by  adding  the 
relevant  s-goals  to  a  set  of  active  goals.  Responses  to  this  agent’s  own  requests  are  in¬ 
corporated  in  the  local  fsasibllty  tree  and  used  as  additionai  knowledge  in  making 
revisions  to  Its  tentative  commItmenL 
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4.  The  set  of  active  goals  consists^  aR  the  local  pijoals  together  with  those  s-goals  that 
have  been  added  (In  step  3).  The  agent  rates  the  alternatives  associated  with  active 
goals  based  on  their  cost,  any  confirming  evidence  that  the  alternative  is  a  good 
choice,  any  negative  evidence  in  the  form  of  nonlocai  conflict  information,  and  the  im¬ 
portance  of  the  goel  (lH}oal,  8-goal,  etc.).  A  revised  tentative  commitment  is  made  to  a 
highest  rated  set  of  locdHy  consistent  aitematives  for  active  goals.  In  general,  this  may 
involve  decisions  to  add  plan  fragments  to  the  tentative  commitment  and  to  delete 
plan  fragmerts  from  the  old  tentative  eommitmara.  Messages  reflecting  any  changes 
in  the  tentative  commitment  and  perceived  conflicts  with  that  commitment  are  trans¬ 
mitted  to  the  appropriate  agents. 

5.  The  incoming  message  queue  is  examined  egain  and  activity  proceeds  as  described 
above  (from  step  3).  The  process  of  aggregating  knowledge  about  nonlocai  conflicts 
continues  urttB  a  node  is  aware  of  aii  conflicts  in  which  its  plan  fragments  are  a  con¬ 
tributing  foctor. 


Bfimada 

Each  of  the  preceding  algorithms  suggests  ways  to  implement  some  aspect  of  a  routing 
algorithm  for  a  CNCE  network.  The  Linear  Programming,  Maximum  Row,  Minimum  Cost  Row, 
and  Shortest  Path  methods  are  important  tools  ultimately  for  system  planning.  All  four  optimize 
resources  as  their  narrtes  suggest,  making  them  useful  for  the  initial  layout  of  a  network.  However, 
in  their  present  Implementation  each  requires  global  knowledge  of  the  system  network  and  can 
not  be  directly  incorporated  into  a  distrfouted  CNCE  network  without  some  form  of  modification. 

The  DNCS  Algorithm  3  shows  that  by  storing  the  current  network  status  in  each  node  of 
the  network,  the  Shortest  Path  method  can  overcome  the  global  knowledge  limitation,  but  oniy  at 
the  expense  of  multiple  system  updates  every  time  a  node  or  link  changes.  Algorithm  1  exhibits 
the  most  promise  as  a  feasible  algorithm  for  CNCE  network  allocation.  It  meets  the  requirements 
of  not  needing  global  information  yet  goes  about  its  business  without  a  multitude  of  update 
messages.  Using  a  two-sweep  process,  the  first  phase  locates  all  connected  nodes  while  the 
second  phase  r^ums  to  the  sender  information  about  the  cost  and  route  of  the  circuit.  Although 
simple  in  concept  and  nxxlular  in  design.  Algorithm  1  relies  on  timeKiut  messages  to  terminate.  It 
also  does  not  optimize,  instead  leaving  a  cost-rartked  choice  of  possible  routes  for  the  technical 
controller  to  choose  from.  This  opetverxledness  may  not  be  much  of  a  drawback  as  it  allows  the 
technical  controller  to  deal  flexibly  with  a  wide  range  of  constantly  changing  external  information. 


23 


I 


I 


The  constraint-based  approaches  provide  useful  insight  on  how  to  formulate  a  CNCE 
allocation  algorithm.  The  Waltz  algorithm  In  particular  shares  many  simlarities  with  the  Minimum 
Cost  Flow  algorithm  and  Algorithm  1 ,  yet  k  terminates  with  an  optimal  solution.  Lastly,  Multistage 
Negotiation  suggests  a  way  to  minimize  disruption  among  established  circuit  users  during 
preemption,  a  problem  of  global  dimensions  that  requires  a  dtetributive  means  of  resolution. 
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This  study  employs  a  two-step  approach  to  achieve  resource  allocation  ends;  incorporate 
the  main  features  of  a  tactical  communications  network  into  an  ot^ect  oriented  program  (OOP), 
and  graphically  show  how  the  obiects  react  during  search  and  allocation  processes.  More 
precisely,  the  foHowing  pages  present  the  design  impiementation  in  terms  of  these  core  ideas; 

1)  design  goals,  2)  OOP  classes,  3)  saturation  search  algorithm,  4)  commands  and  tools  to 
facilitate  route  planning,  and  S)  graphics  display.  Although  equipment  constraints  steered  the 
design  toward  a  Prototype  Route  Planner  (PRP)  to  be  used  in  the  initiai  construction  of  a  ONCE 
network,  a  related  goal  throughout  remained  tiM  development  of  the  Technical  Controller’s 
Assistant  (TCA),  a  semi-automatic  route  planning  system,  distributed  to  every  CNCE  in  a  network, 
that  would  help  technical  controllers  at  these  rKxies  deal  with  massive  restructuring  requests  by 
finding  viable  routes  for  them.  The  two  projects  share  common  development  stages;  only  the  final 
applications  differ.  In  the  Technical  Controller’s  Assistant,  copies  of  a  modified  routing  algorithm 
would  be  placed  in  each  CNCE  of  a  tactical  network.  When  conditions  warrant  finding  a  new 
route,  a  human  technical  controller  calls  on  TCA  to  find  a  route,  and  another  operator  authorizes 
the  ensuing  choice.  In  contrast,  PRP  simulates  an  entire  CNCE  network,  permitting  one  person  to 
build,  modify,  and  generate  circuits  on  a  healthy  or  damaged  network  using  the  same  principles 
as  TCA 

Deafqn  Goala 

This  study  derives  It  des^n  goals  from  conversations  with  communications  people  who 
are  famliar  with  CNCE  networks.  The  following  goal  statements  reflect  constraints  imposed  by 
real-world  conditions  and  perceived  areas  of  Improvement. 

•  The  system  should  be  able  to  pick  a  circuit  path  without  relying  on  stored  aitematives. 


One  problein  with  the  cunent  method  of  route  planning  is  that  technical  controllers  must 
rely  on  backup  plans  to  restore  a  circuit,  should  it  go  bad.  Durkig  peace-time  this  system  works 
well,  since  malfunctions  Irtfrequentiy  occur.  The  situation  couid  be  quite  different  during  war,  when 
coordinated  attacks  might  render  significant  portions  of  the  network  Inoperative.  Circuit 
re^oration  under  these  circumstances  wH  most  IHcely  proceed  ki  an  ad  hoc  manner  as  it  is  highly 
unlikely  that  a  backup  (lian  wU  cover  the  exact  ntrture  of  the  damage.  As  it  starxls  today,  technical 
controllers  in  surviving  CNCEs  will  communicate  with  other  controllers  to  determine  the  extent  of 
the  damage,  then  restore  service  to  high-priority  circuits,  preempting  low-priority  circuits  as 
necessary,  relyir^g  on  backup  plans  whenever  they  coincide  with  the  actual  damage. 

e  A  restorative  process  should  function  without  knowing  the  overall  status  of  the  network. 

During  the  crucial  first  few  moments  of  an  attack,  technical  controllers  throughout  the 
network  must  learn  of  the  network’s  global  status  before  they  can  meaningfully  restore  circuits. 
This  information-gathering  period  comes  at  a  time  when  commanders  need  the  damaged 
dedicated  circuits  most  Clearly  an  approach  that  bypasses  or  eliminates  the  fact-finding  stage, 
would  hasten  restoration  efforts. 


e  The  system  should  provide  path  information  but  allow  human  intervention  and  authoriza¬ 
tion. 

A  fully  automatic  route-planning  system,  one  that  plots  and  activates  a  route 
autonomously,  will  most  likely  suffer  from  insufficient  route-planning  information,  since  some  of 
the  Information  needed  to  route  a  droA  could  come  from  external  sources.  Currently,  If  a 
technical  controller  is  aware  of  outside  Information,  such  as  the  location  of  an  enemy  attack,  he 
can  route  circuits  away  from  the  battle.  On  the  other  hand,  a  fully  automatic  route-planning  system 
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would  pick  an  optimum  route  based  on  pre-programmed  ideals,  oblivious  to  the  benefits  a  longer 
but  safw  route  has  to  offer. 

•  The  system  must  accommodate  prioritized  circuits. 

Mlitary  communications  networks  dHfer  from  cMiian  networks  in  that  the  military 
preempts  low  priority  circuits  as  necessary  to  ensure  that  high  priority  circuits  get  through.  To  be 
of  benefit,  a  routing  algorithm  must  reflect  the  same  preemption  decisions  that  a  technical 
controller  would  make. 

•  The  system  should  work  with  limited  computer  resources. 

Each  CNCE  hosts  a  rugged  but  small  computer  that  currently  operates  a  database.  The 
system  has  64K  of  memory  and  permar>ent  disk  storage,  but  the  computer  has  little  room  for 
additional  furKtions  and  quite  possibly  may  be  inadequate  for  routing  functions.  The  above  goals 
sketch  out  desirable  features  for  either  the  PRP  or  the  TCA.  The  next  section  details  how  to 
quantify  network  features  so  as  to  be  able  to  work  towards  these  goals,  from  the  perspective  of 
the  PRP. 

Object  ChMW 

There  are  two  fundamental  reasons  for  using  object  oriented  programming  as  a  tool  to 
tackle  the  tactical  communications  route-planning  problem.  First,  object  oriented  code  extracts 
the  salient  featises  of  a  network,  faclitating  network  models  (this  process  is  also  known  as 
abstraction,  Booch,  1987:12).  Whether  capturing  main  ideas  for  a  proof-of-concept  prototype,  or 
expanding  those  Ideas  into  an  operational  system,  an  object  oriented  design  groups  data  and 
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function  into  an  object  that  behaves  as  would  Its  reai-woild  counterpart,  thus  permitting 
code-objects  to  accurately  represent  their  physical  counterparts. 

Second,  object  oriented  programming  simpines  the  code’s  design  by  breaking  it  into 
small,  logical  parts.  By  splitting  the  network  Into  component  classes  (CIRCUIT,  node,  LINK,  and 
CHANNEL^,  the  programmer  can  detal  the  workings  of  each  object  This  modularity  (Booch, 
1987:12)  yields  simple  objects  with  specific  tasks,  that  when  thrown  together  with  other  objects, 
work  in  corrcert  to  perform  complicated  procedures. 

An  unexpected  benefit  of  using  object  oriented  programming  for  this  study  is  that 
simplifications  made  within  the  code  suggest  sMUtr  simplifications  could  be  made  within  an 
actual  CNCE  network.  The  next  chapter  covers  these  simplifications  and  what  they  mean  in  more 
detal,  the  point  being  that  It  would  be  hard  to  develop  and  test  improvements  with  hardware 
alone. 

Before  going  further,  a  quick  discussion  on  the  choice  of  development  languages  is  in 
order.  Any  language  that  contains  object  extensions  can  be  used  to  mcxlel  CNCE  networks. 
Flavors,  allied  with  the  powerful  Lisp  language  was  used  initially  to  carve  out  a  rough  draft  of  the 
main  objects.  The  author’s  famliarity  with  Flavors,  and  an  abundance  of  technical  help  paved  the 
way  for  rapid  conversion  of  ideas  into  code.  However,  after  a  week  and  a  half  of  development,  a 
decision  was  made  to  switch  to  a  simlar,  but  simpler  language,  PC  Scheme.  By  changing  to 
Scheme  and  Its  object  oriented  extension  Scoops  (Scheme  Object  Oriented  Programming 
System),  the  author  retained  the  lisp-like  features  of  the  first  draft,  and  gained  a  development 
language  that  could  execute  on  an  small,  I.BM  XT  class  computer  (small  when  compared  to  the 
exotic  Symbolics  machine  that  Flavors  resides  on),  (Texas  Instruments,  1987:1-1).  This  theme  of 
small  computer  development  is  in  keeping  with  the  design  goals  and  maiities  of  CNCE  networks. 
Although  Scheme  cannot  be  used  directly  on  a  CNCE’s  computer,  the  fact  that  the  entire 
development  language  fits  in  a  small  computer  suggests  that  a  final  version  could  reside  happily 
on  a  machine  no  larger  than  one  with  640K  of  memory  and  a  hard  drive  for  permanent  storage. 

• 
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In  an  object  oriented  design,  a  good  deal  of  time  is  spent  analyzing  how  system 
sub-components  Interface,  so  that  when  it  comes  time  to  write  the  procedures  that  give  objects 
character,  a  natural  interactive  Nerarchy  wU  already  be  in  place.  In  PC  Scheme,  the  class 
definition  detals  each  object’s  attributes.  PRP  uses  five  IDENTITY,  NODE,  LINK, 

CHANNEL,  and  CIRCUiT,  to  represent  physical  entties  and  cormrKm  properties.  The  following 
paragraphs  explain  the  purpose  and  place  of  each. 

IDENTITY  Hto— -  A  dass  acts  like  a  template,  defining  features  common  to  all  its 
offspring.  These  offspring,  referred  to  as  Instantiations,  share  the  same  instance  variable  names 
defined  by  their  class,  but  the  contents  of  these  variables  vary  depending  on  the  instance.  For 
i  example,  all  objects  in  PRP  share  a  dass  called  IDENTITY.  The  IDENTITY  dass  owns  two  instance 


(define-class  IDENTITY 
(Instvars  Name 

(Status  ’Alive)) 

(options  (gettable-variables  Name) 
(settable-variables  Status) 
(inittable-variables  Name))) 


Figure  4.  Identity  Class  Declaration 


variables,  NAME  and  STATUS  (figure  4).  NAME  stores  the  title  given  an  instance  while  STATUS 
stores  its  condition  (dead  or  alive).  No  two  objects  share  the  same  name,  yet  any  object  will 
respond  with  its  given  tWe  whenever  queried  through  the  comnxxi  instance  variable  NAME.  The 
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same  holds  for  STATUS.  Some  objects  may  be  deed,  and  others  alive;  querying  an  object’s 
STATUS  determines  the  answer.  Unique  among  classes,  the  IDENTITY  class  does  not  represent  a 
physical  entity  in  the  tacticai  network.  Instead,  other  dasses  inherit  this  basic  information, 
reducing  the  complexity  of  the  code. 

NODE  Claaa.  A  node  represents  a  ONCE,  it  contains  procedures  that  implement  the 
routing  algorithm,  serves  as  the  entry  point  for  circuit-requests,  and  the  exit  point  for 
circuk-replies.  Nodes  connect  atiy  to  links  (trunks)  and  store  a  finite  number  of  circuit-request  and 
drcuk-relay  messages  that  pass  through  the  node  enroute  to  other  nodes.  An  instance  variable 
called  REQUESTS  (figure  5)  stores  the  request-messages  in  list  form.  Likewise,  an  instance 


(define-class  NODE 

(ciassvars  (Population  0)) 

(mixins  IDENTITY) 

(instvars  (Rectangle  (make-window  #F  #T)) 
(Serial-Number  (set!  Population  (1  + 

Population))) 

Requests 

Replies 

Links) 


Figures.  Node  Class  Dedaration 


variable  called  REPLIES  retains  final  path  information,  also  in  list  form.  Since  a  node  talks  only  to 
those  links  attached  to  it,  it  must  request  channel  and  circuit  information  directly  from  the  link. 
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Note  that  a  node  Is  \inaware*  of  its  node  neighbors  and  the  channels  that  carry  message  traffic  for 
the  link.  In  an  analogous  sense,  a  technical  controller  deals  primarly  with  the  trunk  lines  that 
terminate  at  his  CNCE,  using  Indirect  trouble-shooting  methods  to  obtain  channel  and  neighbor 
CNCE  Information. 

LINK  Class.  A  link  represents  a  trunk  ikie  and  functions  so  as  to  propagate  information 
from  end  node  to  end  node.  A  link  knows  which  nodes  mark  Its  boundaries  and  it  knows  the 
channels  assigned  to  it,  just  a  microwave  trunk  ilr^e  can  be  characterized  by  its  termination  points 
and  the  twenty-four  T-1  channels  It  carries.  This  Information  Is  stored  in  list  format  in  the  NODES 
and  CHANNELS  instance  variables  (figure  6).  The  link  however,  does  not  know  if  a  channel  has 
been  assigned  to  a  circuit  This  Information  must  be  found  out  by  querying  the  channel  and 


(define-class  LINK  •  • 

(mixins  IDENTITY) 

(Instvars  (Score-Board  (make-window  #F  #F)) 
Nodes 
Channels) 

(options  gettabie-variables 
settable-variables 
(inittable-variables  Nodes))) 


Figure  6.  Link  Gass  Declaration 


parallels  the  signal  check  a  technical  controller  makes  to  determine  if  a  channel  carries  data.  The 
query  process  breaks  from  reality  In  that  a  trunk  can  not  interrogate  a  channel.  Instead,  the 
technical  cornier  determines  the  Information  using  test  signais  or  representative  information 
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stored  in  a  data  base  or  written  on  cards.  In  any  event  a  link,  like  its  trunk  counterpart,  effectively 
bundles  ail  channel  information  Into  one  entity  for  easier  handling. 

CHANNEL  Claea.  Channels  represent  a  resource  capable  of  carrying  messages. 
Channels  know  which  link  they  belong  to  and  the  circuit  they  carry.  This  information  resides  in 

t 

'  LINK  and  CIRCUIT  Instance  variables  respectively  (figure  7).  A  real-life  channel  can  be  tested  for  a 

carrier  signal  to  determine  if  it  carries  a  circuit,  whte  the  absence  of  a  carrier  signifies  that  the 
I  channel  remains  unused  (or  has  malfunctioned).  In  actuality  a  channel  does  not  associate  itself 


(define-class  CHANNEL 
(mixins  IDENTITY) 

(instvars  Link 

(Circuit  (active  ’Spare  #F 
auto-connect-Circuit))) 

(options  gettable*variabies 


Figure  7.  Channel  Qass  Declaration 

with  a  link  except  by  physical  location  arxl  it  does  not  know  the  identity  of  the  circuit  it  carries,  but 
records  maintained  at  a  CNCE  will  show  channel-circuit  pairs  and  the  trunk  to  which  a  channel 
belongs.  For  this  reason  the  CHANNEL  class  permits  direct  communication  with  links  and  circuits. 

CIRCUn'  Circuits  constitute  the  end  result  of  the  Prototype  Route  Planner.  They 

carry  messages  from  one  destination  to  another  via  Intermediate  points  as  do  their  physical 
counterparts.  This  object  Includes  a  priority  attribute  and  a  list  of  channels  that  form  a  path 
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between  the  two  end  points.  This  representation  departs  from  reaiity  in  that  a  reai  circuit  does  not 
keep  track  of  the  channels  it  uses.  Instead,  a  data  base  or  card  system  describes  the  allocated 
channels.  The  circuit  is  assigned  a  priority  but  again,  it  does  not  intrinsically  know  that  priority 
while  the  rfata  base  does.  This  poses  a  reai  worid  problem  because  a  circuit’s  priority  can  change 
while  not  immediately  affecting  the  resources  allocated  to  It  Later  preemptions  can  cause 
problems  if  the  "robbing"  circuit  is  not  aware  of  the  upgraded  priority  of  the  "victim"  circuit. 

Meaaaoe  Imoiementatlon 

Messages  govern  network  operation  in  this  Implementation,  and  although  they  play  a 
major  part  in  a  CNCE  network,  they  do  not  warrant  a  separate  class  for  two  reasons.  First,  an 
object-like  message  representation,  however  suitable  for  computer  simulation,  could  not  be 
applied  directly  to  operational  use  due  to  the  inherent  complexity  of  the  message's  data  structure 
(objects  cannot  be  passed  between  computers).  Instead,  a  list  format  translates  easier  due  to  its 
string-like  appearance.  Second,  let  us  assume  that  a  message  can  take  object  form.  Then  for 
every  message  created,  additional  copies  would  be  needed  for  distribution  throughout  the 
network.  As  these  copies  move  about,  they  paradoxically  store  path  information  that  distinguishes 
them  from  each  other.  Unfortunately,  once  instantiated,  an  object  can  not  be  split,  and  even  if  it 
could,  one  would  run  into  a  data  structure  problem— object  oriented  languages  all  have 
convenient  ways  to  create  objects,  but  few  include  a  graceful  way  to  destroy  objects  without 
contaminating  related  data  structures.  For  this  reason,  object  instantiations  under  this  format 
would  continue  to  grow  until  they  exhaust  computer  memory,  or  until  program  termination  when 
the  computer,  upon  releasing  memory,  effectively  eradicates  all  objects. 

Saturation  SearcliAlqocIttim 

For  several  reasons  the  saturation  search  algorithm  first  Introduced  by  Ludwig  and  Roy 
fulfills  the  requirements  for  a  route  planning  system:  1)  The  saturation  search  algorithm  provides  a 
convenient  way  to  work  around  damaged  nodes  and  links  without  devoting  large  amounts  of 
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computar  memory  to  nx}nitoring  the  netvMXk's  operational  status,’  2)  The  route  pruning  features 
Inherent  in  the  algorithm  reduce  the  number  of  messages  that  drcuiate  through  the  network;  3) 
The  algorithm  does  not  rely  on  global  Information,  fadttating  Its  use  in  a  distributive  environment. 
Both  the  Prototype  Route  Planner  and  the  Technical  CoittroUers  Assistant  benefit  from  this 
algorithm  and  the  priorttization  scheme  proposed  by  Computer  Services  Corporation  for  use  in 
the  DP  AS  Network  Control  System. 

Figure  8  shows  the  message  format  used  in  the  PRP.  As  the  message  is  really  a  list,  it  can 
be  easily  copied  and  modified  using  Scheme  operators.  In  PRP  it  remains  in  list  form  as  it  moves 
from  link  to  node.  In  the  TCA,  the  message  would  be  converted  to  a  string,  then  broadcast  over 
trunks  to  adjacent  nodes  for  further  use.  Three  messages,  request,  reply,  and  reject,  dictate  the 
algorithm's  mode  for  nodes  (figure  9)  and  links  (figure  10).  A  request-message,  generated  by  a 
technical  controller  through  the  use  of  the  Make-Circuit  command,  initiates  the  algorithm.  The 
origin  node  builds  the  request-message,  repeating  it  to  every  link  it  connects  to.  Each  link  passes 
the  message  to  the  node  at  the  opposite  end.  The  node  records  the  message  then  relays  it  to 
every  connecting  link.  As  long  as  a  single  link  connects  an  isolated  node  to  the  network's  bulk,  a 
request-mer<sage  sent  by  the  node  will  propagate  through  the  network  reaching  every  other  node 
in  the  net  This  tenacious  quality  proves  beneficial  for  tactical  networks  as  it  inherently  protects  the 
network  from  CNCE  and  trunk  dantage.  Redundant  message  traffic  is  the  price  paid  for  survival. 

Message  Attenuation.  If  not  for  certain  attenuating  principles,  request  messages  would 
echo  forever  within  a  network.  One  such  attenuator,  message  cost,  works  even  in  a  prioritized 
system.  Consider  a  request  for  an  A-priorfty  circulL  Its  request  message  shows  [10  0  0]  as  its 
priority  vector.  Next,  assume  that  one  of  tiie  paths  traveled  by  the  request-message  yields  one 
B-priority  channel,  one  C-priority  channel,  and  one  spare  channel  as  a  possible  path  combination. 
This  three-hop  path  shows  a  cumulative  cost  of  [0 1 1 1] ,  meaning  one  B-priority  circuit,  and  one 
C-priority  circuit  would  have  to  be  sacrificed,  arxi  one  spare  would  have  to  be  expended  to 
complete  the  A-priority  request.  If  at  this  same  node,  a  subsequent  request-message  discloses  a 
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cumulative  cost  vector  of  [0 1  2  0] .  the  node  would  not  transmit  this  message  to  its  connected 
links  as  Its  proposed  path  preempts  an  additional  C-priority  circuit,  making  this  route  more 


(CircuK-ID  Mode  Destination  Priority  Previous-Cost  (Path)) 
where: 

CIrcuit-ID  =  Circuit-X 

Mode  =  Request,  Repiy,  or  Reject 

Destination  =  Circuit  termination  CNCE 

Priority  =  [1  0  0  0],  [0  1  0  0],  or  [0  0  1  0], 
for  A,  B,  or  C  priorities  respectively 

Previous-Cost  =  [????] 

(Path)  s  (Destination,  Unk-Y,  Nod6-Z...Origin) 

Figures.  Message  Format 


expensive  than  the  first.  The  aigorithm  goes  one  step  further  by  biocking  alternate  routes  of 
identical  costs,  so  that  only  inexpensive  routes  generate  repeat  messages. 

A  second  message  attenuator  works  on  an  allocation  principle;  if  a  request  message 
warrants  preemption  of  existing  circuits,  relay  the  message,  otherwise  terminate  it.  This  principle 
weeds  out  saturated  path  segments  In  tavor  of  unsaturated  paths.  For  example,  if  an  A-priority 
circuit-request  reaches  a  node  connected  to  two  links,  each  with  single  channels  already 
dedicated  to  circuits,  the  following  would  happen.  The  node  asks  the  first  link  what  priority  traffic  it 
carries.  When  ft  replies  B-priority,  the  node  relays  the  message  since  an  A-priortty  request  can 
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Figure.  10  Link  Row  Chart 


preempt  B  and  Opriortty  channels.  When  the  second  link  answers  that  it  carries  another  A-priority 
channel,  the  node  bypasses  this  link  since  a  request  can  not  preempt  channels  of  equal  or  higher 
priority.  During  this  channel  check,  no  channels  are  allocated.  To  do  so  would  be  premature  since 
a  request  message  has  no  guarantee  that  the  proposed  path  It  carries  will  work,  or  that  the 
destination  node  even  exists. 

M— pfopagatlon.  As  a  request  message  propagates  through  the  network,  each 
node  stores  a  copy  of  It  in  the  instance  variable  REQUESTS.  REQUESTS  always  stores  the  initial 
request  message,  updating  the  message  qniy  if  it  learns  of  a  less  expensive  route.  To  prevent 
confusion,  each  circuit-request  must  have  a  unique  Identity  to  distinguish  it  from  circuit-requests 
generated  elsewhere  in  the  network.  In  little  time  a  node's  REQUESTS  depository  would  fill  with 
new  and  dated  request-messages,  posing  a  memory  capacity  problem  if  It  were  not  for  the  fact 
that  a  first-in  first-out  (FIFO)  buffer  limits  the  number  of  messages.  The  size  of  the  buffer 
determines  the  number  of  simultaneous  circutt-requests  the  network  is  capable  of  handling.  If  too 
large,  the  algorithm  could  suffer  performance  penalties  due  to  excessive  search  times.  If  too  small, 
the  buffer  will  dump  path  information  forcing  a  node  to  pass  on  a  message  it  might  normally 
terminate. 

Given  a  viable  network  and  a  circuit  request,  the  request  message  will  reach  its 
destination.  The  destir^tion  node  places  the  path  carxiidate  from  the  message  in  the  instance 
variable.  Replies.  As  other  alternate  route  nrressages  reach  their  destination,  they  too  contribute 
paths  to  Replies  providing  the  path  cost  does  not  exceed  that  of  the  least  expertsive  route  stored 
so  far.  Thus,  unlike  a  support  node  that  passes  only  least-cost  information,  a  destination  node 
retains  low  arxi  equal  cost  alternatives  so  that  the  technical  controller  can  choose  the  best  route 
based  on  external  information.  This  feature  works  toward  the  design  goal  of  incorporating  outside 
information  into  the  choice  of  routes. 

Once  a  request  message's  path  can  be  determined,  the  algorithm  then  must  allocate 
channels  along  the  path  atxl  in  doing  so  establish  the  circuit.  This  allocation  phase  works  from  the 
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destination  node  backwards  to  the  origin  nods  and  commences  when  the  technicai  controller 
specifies  a  route  with  the  Pick  Route  (PR)  command.  The  destination  node  first  records  the  choice 
in  Replies  and  then  generates  a  reply-message  for  channel  allocation.  Unlike  the  original  version 
of  the  algorithm  which  relies  on  route  information  stored  fo  Requests  to  back-trace  the  route,  this 
version  carries  path  information  with  it.  prsduding  any  loss  of  path  information  should  the 
Requests  buffer  flush  the  circuit's  request  message. 

Upon  receipt  of  a  reply  message,  each  link  along  the  route  picks  a  channel  to  allocate  to 
the  circuit  The  same  identification  process  occurred  earlier  when  each  link  verified  it  could 
support  the  circuit.  A  second  check,  warranted  by  virtue  of  the  fact  that  a  competing  circuit  may 
have  stolen  the  previously  identified  charmei,  reaffirms  that  a  channel  still  exists  and  confirms  the 
circuit's  viabBity  to  this  point  As  ior^l  as  a  suitable  channel  exists,  the  allocation  process 
continues.  If  not  the  node  where  the  bri^ch  occurred  generates  a  reject  message,  signalling  that 
the  allocation  process  can  go  no  further. 

The  reject  mode  de-allocates  ail  channels  recently  assigned  to  the  circuit  and  warns  the 
technical  controller  who  picked  the  route  to  choose  a  new  orte  from  the  alternates.  If  no  alternates 
exist  the  technical  controller  who  originated  the  request  will  re-initiate  the  circuit  after  waiting  a 
specified  period  of  time  for  the  circuit  to  go  through.  The  rejection  process  frees  channels  by 
undoing  each  allocation  one  at  a  time,  from  the  point  of  conflict  to  the  destination  node.  When  the 
reject  message  reaches  the  destination  node,  it  warns  the  technical  controller  via  a  text  message 
or  audio  alarm. 

Command  Languagg 

Four  commands,  Make-Circuit  (MC),  Pick-Route  (PR),  Dead,  and  Alive,  make  up  the 
vocabulary  in  the  Prototype  Route  Planner's  language.  The  first  two  commands  interface  directly 
with  the  route  planner,  whBe  the  last  two  control  external  changes  to  the  network.  In  a  TCA 
version,  the  technical  controlier  at  a  CNCE  would  use  a  simplified  form  of  MC  and  PR  to  build 


39 


network  circuits.  The  Dead  and  Alive  commarKls  would  not  exist  as  the  environment  assumes 
responsibitty  for  incapacitating  equipment 

Make-Cireuit  Command.  From  a  TCA  perspective,  the  Make-Circuit  command  lets  a 
technicai  controUer  express  the  need  for  a«irctA  from  his  CNCE  to  another.  Either  end  can  invoke 
the  command,  but  a  protocol  that  eliminates  the  an^jiguity  would  also  preclude  redundant  circuit 
requests.  The  author  suggests  that  the  originating  CNCE  should  be  subordinate  to  the  destination 
CNCE  since  the  destination  CNCE  ultimateiy  authorizes  the  route  choice  (but  only  if  the  junior 
node  identifies  the  need). 

in  the  PRP  Implementation,  the  network  planner  enjoys  a  world  view  of  the  network  and 
assumes  the  technical  controiier  role  for  every  node,  requesting  circuits  between  any  two  CNCEs 
without  the  need  for  a  protocol.  The  command  takes  the  form:  (MC  Origin  Destination  Priority) 
where  MC  denotes  the  Make-Circuit  commarxi.  Origin  determines  the  node  that  will  generate  the 
request-message.  Destination  identifies  the  terminating  rxxie.  and  Priority  takes  A.  B.  or  C  as 
priority  values  for  the  proposed  circulL 

The  origin  node  identified  by  Make-Circuk  creates  a  serial  number  for  the  tentative  circuit 
to  distinguish  It  from  other  requests,  generates  a  request  message,  then  hands  control  of  the 
request  to  the  network  for  execution.  The  Make-Circuit  command  goes  no  further.  It  is  up  to  the 
algorithm,  the  destination  controller,  and  fete  to  determine  if  the  circuit  will  go  through.  Of  course 
the  route  planner  wil  have  a  good  idea  if  a  circuit  wOi  go  through  since  he  determines  the 
environment  and  monitors  messages  as  they  course  through  the  network.  This  does  not  mean 
however,  that  Make-Circuit  is  a  one-shot  forget-aU  command.  In  the  TCA,  if  the  originator  does  not 
receive  confirmation  of  the  new  circuit's  existence  after  a  sufficient  period  of  time,  then 
Make-Circuit  should  be  tried  again;  the  delay  may  be  due  to  channel  conflicts  arising  in  ways 
alluded  to  eariier. 

Plek-Botite  Command.  The  Pick-Route  commarxi  authorizes  one  route  for  channel 
allocation  aixl  sets  in  motion  the  circuit  bulding  process.  In  a  typical  situation,  a  route  planner 
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uses  Pick-Route  after  all  message  passing  activity  stops  and  time  permits  the  finalization  of  circuit 
The  command  takes  the  form:  (PR  Numbed  where  PR  derKtes  the  Pick-Route  command,  and 
Number  determines  which  node  should  be  examined  for  unresolved  circuit  paths.  Pick-Route 
need  not  be  applied  immediately  after  a  Make-Circuit  request  since  Replies  storm  a  finite  number 
of  solutions  In  a  first-in  first-out  buffer  Just  as  Requests  does.  But  If  the  route  planner  fails  to  act  in 
time,  a  fun  buffer  wM  flush  unresolved  circuits  as  additional  circuits  come  in. 

The  Pick-Route  command  displays  circuit  Information  In  tabular  form,  on  a  first  arrived, 
first  answered  basis.  Pick-Route  numbers  the  choices,  displays  path  cost,  showvs  the  routes,  then 
prompts  the  planner  for  a  choice.  The  number  one  choice  wfll  always  show  a  least  expensive 
route.  Successive  choices  wll  show  routes  of  equal  or  greater  expense.  Thus  a  route  planner  can 
bund  a  low  cost  network  by  picking  routes  at  die  top  of  the  list.  The  planner  however,  has  the 
freedom  to  pick  any  route  or  abort  the  selection  process.  If  a  legitimate  choice  is  made, 

Pick-Route  constructs  a  reply  message  which  is  dispatched  to  the  destination  to  complete  the 
allocation  process.  The  command  also  creates  an  instance  of  the  circuit,  named  after  its  circuit  ID 
to  accommodate  channel  information  incurred  while  building  the  circuit.  This  instantiation  creates 
the  circuit  as  an  object  even  though  it  owns  no  channels  at  that  moment. 

Pick-Route  also  codes  the  selected  route  information  within  Replies  and  preserves  the 
unchosen  alternates.  If  the  chosen  route  does  not  go  through,  the  ensuing  reject  message  alerts 
the  route  planrter  to  re-apply  Pick-Route  to  choose  an  alternate  route.  When  used  in  this  manner 
Pick-Route  annotates  the  H-fated  circuit  so  that  ft  wll  not  be  tried  again  by  mistake 

Dead  Command.  The  Dead  command  kUs  any  instance  of  a  node,  link,  channel,  or 
circuit  dass.  The  conwnand  works  in  conjunction  with  the  iOENlTTY  class  which  is  an  inherited 
part  of  all  objects.  If  an  object  is  klled  with  the  command  (Dead  Object),  the  status  instance 
variable  of  that  ot^ect  win  be  set  to  'dead.  A  cardul  examination  of  the  methods  (procedural  code) 
assigned  to  each  class  of  object  reveals  that  an  object  wfll  not  perform  programmed  tasks  if  it  is 
dead.  This  is  the  result  of  an  if-ciause  or  other  related  conditional  statement  at  the  beginning  of 
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each  method.  A  dead  obfect  returns  nl  as  Its  value,  adding  no  information  to  the  network  and 
demanding  no  work  from  associate  ot^ecla.  in  surtwnaty,  a  dead  object  stU  takes  up  space  In  the 
network,  but  does  not  respond  to  inputs. 

Alive  Command.  The  Alive  command  rejuvenates  any  dead  object,  returning  Its  Status 
instance  variable  to  the  value  'alive.  The  condttlonai  statements  at  the  beginning  of  each  method 
check  for  an  aiive  object  before  they  continue  ocecutioa  An  object  can  be  kHled  and  reincarnated 
as  many  times  as  necessary  by  the  route  planner,  but  the  user  is  warned  that  PRP  makes  no  effort 
to  remove  dead  objects.  They  reside  in  memory  unti  the  session  terminates  and  in  large  network 
simulations,  could  consume  a  good  amount  of  memory. 

insoectlon  Tools 

Inspection  tools  fall  Into  two  catagories,  those  that  help  the  route  planner,  and  those  that 
help  the  programmer.  The  first  category  includes:  Channels?,  Drcuits?,  Cost?,  Links?,  Nodes?, 
Living?,  and  Look,  which  enable  the  route  planner  to  determine  associations  between  network 
objects.  The  second  category.  Replies?  and  Requests?  are  used  to  monitor  the  messages  stored 
at  a  node  and  for  this  reason  offer  little  useful  information  to  the  route  planner,  but  do  help  the 
programmer  make  sense  out  of  a  long  list  of  data. 

The  route-planner  inspection  tools  use  the  natural  hierarchy  imposed  by  the  object 
classes  to  obtain  information.  The  chain-like  association  starts  at  one  end  with  the  NODE  class. 
Nodes  recognize  links  since  the  LINKS  instance  variable  resides  within  the  NODE  class.  Likewise 
links  recognize  nodes  and  channels,'  channels  recognize  links  and  circuits;  and  circuits,  at  the 
other  end  of  the  chain,  recognize  channels.  The  hierarchy  naturally  limits  how  the  objects  interact, 
but  this  programming  convenience  proves  dlfflcuit  when  it  comes  to  extracting  information  from 
non-adjacent  objects  as  they  do  not  associate  with  each  other.  For  this  reason,  the  inspection 
tools  offer  an  easy  way  to  extrapolate  information  outside  the  chain.  For  example,  the  query 
(Links?  Node-1 )  causes  Node-1  to  output  a  list  of  the  links  It  owns  (the  list  will  not  be  readable  due 
to  the  internal  representation  of  objects,  but  the  Look  command  presented  later  overcomes  this 
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restriction).  Since  Node-1  need  oniy  send  die  contents  of  its  LiNKSinstance-vaiiabie,  one  would 
not  expect  this  task  to  be  too  difficult-and  It's  not  V  the  Information  can  be  requested  directly. 
However,  how  can  one  ask  Node-1  about  the  circuits  It  owns  when  It  does  not  have  a  CIRCUITS 
instance-vai1abie?TTie  answer  lies  in  the  hierardiy.  Node-1  asks  all  the  links  connected  to  it  what 
circuits  they  cany.  The  links  In  turn  pass  the  question  to  their  respective  channels.  The  channels 
return  the  answer  to  the  links  and  the  links  pass  the  Infonnation  to  Node-1  which  collects  the 
results  and  offers  It  as  If  it  directly  owned  channels.  This  convention  works  for  all  classes  of 
objects,  as  shown  In  Figure  11. 

Of  the  remaining  commands.  Look  is  used  to  reveal  the  given  name  of  an  object  while 
Living?  asks  if  an  object  is  dead  or  alive.  Look  is  used  in  conjunction  with  the  above  object  query 
tools  in  the  form  (Look  (X?  Object)).  Look  substitutes  a  name  for  the  computer’s  coded 
representation  arKi  will  work  for  any  object  as  tong  as  It  possesses  the  Name  instance  variable 
inherited  by  the  IDENTITY  class.  The  query  (Living?  Object)  returns  a  simple  "dead"  or  "alive” 
response  for  the  object  in  question.  The  tool  uses  information  from  the  Status  instance  variable  to 
determine  the  nature  of  an  object.  One  should  note  that  while  Living?  elicits  a  reply  regardless  of 
death,  other  tools  will  not  work  the  same  way.  If  an  object  is  dead,  it  will  not  be  revealed  by  Look 
or  any  of  the  ot^ect-query  tools  since  the  object  wU  not  respond  to  questions.  Thus  only 
participating  objects  appear  as  answers  to  probes  by  the  inspection  tods. 

GrapMcal  Repreaeolatlgn 

The  Prototype  Route  Planner  (PRP)  displays  individual  nodes  and  links,  and  summary 
channel  information  so  that  the  route  planner  can  observe  the  effects  that  circuit  requests  have  on 
healthy  arxl  damaged  networks.  The  PRP  uses  rectangles  arranged  in  a  ring  to  represent  CNCEs. 
The  circular  arrangemertt.  although  It  does  not  preserve  true  network  geometry,  does  retain  the 
one-to-one  functional  relationship  between  links  and  nodes.  The  open  area  in  the  middle  of  the 
ring  provides  space  for  pop-up  windows  like  the  one  that  displays  proposed  route  information  for 
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the  Pick-Route  command.  This  anangement  aiso  minimizes  the  number  of  nodes  that  must  be 
re-dtawn,  since  popHjp  windows  rarely  overlap  the  nodes.  As  a  benefit  the  lines  (trunks)  that 
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Figure  11.  Multi-Object  inspection  Tools 


connect  one  ONCE  to  arxither  do  not  overlap  due  to  the  ring’s  symmetry.  Next  to  each  line  a 
four-place  vector  displays  how  the  channels  have  been  allocated.  The  first  number  details  the 
number  of  channels  used  to  support  A-priprity  circuits;  the  second,  B-priority  circuits;  the  third, 
C-priority  circuits;  and  the  fourth,  spare'  cfunnels. 

The  Prototype  Route  Planner  higNights  indh/iduai  nodes  and  links  as  they  participate  in 
the  allocation  algorithm.  Dead  objects  show  up  in  a  ghost-like  gray  color,  while  nodes  and  links 
take  purple  and  green  hues  respectively.  During  the  algorithm's  final  channel  allocation  phase,  the 
links  that  support  the  circuit  path  turn  red  to  temporarly  Uerrtify  the  new  circuit's  route.  In 
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addition,  as  the  aigodthm  commits  channels  to  the  circuit,  each  iink  updates  the  aiiocation  vector 
to  show  its  channel  content 


This  section  summarizes  key  corKepts  developed  In  the  first  four  chapters  and  then 
examines  the  study's  results.  More  specifically,  it  assesses  the  advantages  and  limitations  of  the 
Prototype  Route  Planner,  the  saturation  routing  algorithm,  and  predicts  how  the  algorithm  would 
act  if  embedded  in  a  tactical  network  in  the  form  of  a  Technical  Controller's  Assistant.  Conclusions 
follow  and  recommendations  for  future  work  completes  the  section. 

Summary 

Technical  controllars  who  run  CNCE  networks  face  time-consuming  resource  allocation 
problems  when  they  configure  or  maintain  a  network.  The  process  of  matching  equipment  to  need 
takes  months  of  planning,  arxt  continues  in  the  field,  where  technical  controllers  manually 
accommodate  last  minute  changes.  To  maintain  a  deployed  network,  controllers  at  each  CNCE 
generally  swap  spare-circuit  resources  for  teiled  dedicated  circuits  according  to  a  pre-determined 
backup  plan;  however,  if  massive  failures  occur  as  they  could  during  an  attack,  the  controllers 
would  preserve  high  priority  circuits  at  the  expense  of  spare  and  low  priority  circuits.  But  before 
they  could  make  effective  restorations,  the  controtleia  as  a  whole  would  have  to  learn  the  extent  of 
the  damage -a  confusing,  lengthy  process  at  best  that  could  be  curtailed  if  there  were  some 
means  to  automatically  allocate  resources. 

An  undirected  graph  describes  the  node,  link,  and  channel  objects  in  a  CNCE  network, 
abstractions  that  assist  an  object  oriented  design  for  the  allocation  problem.  A  CNCE  can  be 
represented  as  a  node,  a  trunk  line  as  a  link,  arxl  channels  in  the  trunk  as  a  multi-element  vector 
that  counts  the  number  of  channels  assigned  to  high,  intermediate,  and  low  priorities,  and  spare 
status.  Each  circuit  is  assigned  a  priority  that  passes  to  the  channels  that  support  it  in  the  network. 
During  the  allocation  process,  a  high  priority  circuit  can  seize  channels  from  circuits  of  lesser 
priority  only.  Regardless  of  a  circuit's  priority,  technical  controllers  try  to  allocate  spare  channels 
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first,  and  high  priority  channels  last  It  follo^  then  that  tiie  cost  of  a  completed  circuit  is  the  sum 
of  the  channels  used,  by  priority.  Although  backup  plans  detail  how  to  compensate  for  some 
losses,  massive  outages  force  ad  hoc  solutions  that  could  be  avoided  if  a  systematic  method  of 
resource  allocation  were  applied. 

r 

r 

Operations  research  search  techniques,  communications  protocols,  and  constraint-based 
sources  were  consulted  in  an  attempt  to  find  an  algorithm  that  can  allocate  channels  in  a 
damaged  network.  Of  the  traditional  routing  algorithms -linear  programming,  the  max  flow 

fc 

algorithm,  the  minimum  cost  flow  algorithm,  and  the  Dijkstra  shortest  path  algorithm  -  all  require 
absolute  knowledge  of  a  network’s  status  before  they  can  function  and  thus  were  not  suitable 
during  massive  outage  situations.  Of  the  DPAS  network  control  algorithms,  both  the  saturation 
search  algorithm  and  a  modified  shortest  path  algorithm  work  in  uncertain  environments,  but  the 
saturation  routing  algorithm  was  chosen  for  implementation  due  to  its  simplicity,  and  low  message 
traffic.  Finally,  although  the  Waltz  algorithm  and  multi-stage  negotiation  methods  suggest  that  they 
would  work  in  an  ONCE  network,  neither  appeared  better  than  the  saturation  routing  algorithm  for 
object  oriented  programming  Implementation. 

Having  identified  network  objects  and  a  routing  algorithm,  the  Prototype  Route  Planner 
(PRP)  was  deemed  the  best  way  to  demonstrate  resource  allocation  in  a  tactical  network  since  a 
fully  functiorral  Technical  Controller’s  Assistant  (TCA)  was  not  physically  practical.  PRP,  which 

r 

resides  in  a  single  personal  computer,  simulates  a  healthy  or  damaged  network  and  employs  the 
saturation  routing  algorithm  to  help  a  technical  controller  find  viable  routes  under  various 
conditions.  A  TCA  demonstration  on  the  other  hand,  would  have  shown  that  a  hard-wired  network 
with  concurrently  running  copies  of  TCA  In  every  personal  computer  node,  could  find  viable  circuit 
routes  among  the  surviving  links  and  nodee  of  a  disrupted  network. 

The  common  design  goals  call  for  a  system  that  finds  routes  without  resorting  to  prior 
planning,  that  functions  without  knowing  the  overall  network  status,  that  permits  human 
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Intervention,  that  accommodates  prioridz^  circuits,  and  that  works  with  limited  computer 
resources. 

PRP’s  object  classes  Include  NODE.  LINK,  CHANNEL,  and  CIRCUIT  classes  and  a 
subordinate  IDENTITY  class  that  standardizes  name  and  status  information.  The  objects  form  a 
hierarchical  ladder  where  nodes  talk  only  to  links,  links  talk  to  nodes  and  channels,  channels  talk 
to  links  and  circuits,  and  circuits  talk  only  to  channels.  The  saturation  search  algorithm  controls 
how  nodes  and  links  rear^  to  requests  for  new  circuits.  A  request  message  ripples  throughout  the 
network  starting  at  the  node  where  it  is  inserted,  travels  along  all  links  that  connect  that  node  to  its 
neighbors,  and  so  forth  until  every  node  hears  the  message.  If  connected  by  a  usable  path,  the 
destination  node  will  eventually  receive  the  message,  store  the  route’s  cost,  and  signal  the 
technical  controller  for  authorization.  Each  node  rejects  dupiicate  messages  when  they  equal  or 
exceed  the  cost  of  the  previous  message  and  repeats  subsequent  low  cost  messages  thereby 
propagating  a  lowest  cost  solution.  The  technical  controller  at  the  destination  picks  a  route,  which 
starts  a  reply  message  back  along  the  winning  path.  On  the  way  channels  are  allocated  to  the 
circuit  or  if  for  some  reason  none  exist,  the  last  participating  node  in  the  allocation  chain 
generates  a  reject  message  that  de-allocates  all  previous  channels  and  warns  the  technical 
controller  to  choose  an  alternate. 

PRP  uses  commands  to  kill  and  revive  network  objects  and  to  manipulate  the  network. 
Inspection  tools  permit  the  user  to  assess  how  individuai  objects  relate  to  one  another.  Finally, 
PRP  uses  graphics  to  depict  the  allocation  process. 

Assessment 

The  algorithm  used  in  the  PRP  behaves  differently  than  the  same  algorithm  would  for  a 
Technical  Controller’s  Assistant  due  to  the  single-computer  implementation  of  PRP.  Although  PRP 
network  objects  appear  as  separate  entities,  the  computer  processes  only  one  object  at  a  time. 


48 


Thus,  a  conunand  that  seems  to  manipitete  several  objects  at  the  same  time,  really  operates  on 
the  objects  sequentially.  As  a  result,  PRP  does  not  enjoy  the  speed  that  TCA  would  with 
parallel-path  processing  capabBItes. 

The  amount  of  time  that  PRP  requires  to  execute  Its  search  algorithm  depends  on  the 
number  of  nodes  and  links  In  the  n^work.  If  nodes  outnumber  links  (possibie  only  In  the  rare  case 
of  a  linear  node  arrangement),  then  the  number  of  nodes  that  handle  the  message  could  decide 
how  quickly  the  algorithm  finds  the  sdutlwi  On  the  other  hand,  if  there  are  more  links  than  nodes, 
then  the  time  spent  exploring  each  link  determines  the  time  to  complete  the  algorithm.  As  the 
routing  algorithm  in  PRP  behaves  like  a  depth-first  search  (DPS),  one  would  expect  a  search  time 
simBar  to  DFS's  0(max  (n.e)),  which  says  that  DPS  executes  in  time  based  on  the  maximum 
number  of  nodes  or  edges  (links)  In  a  network  (Aho  and  others,  1974:178). 

PRP  requires  at  least  the  same  anfeunt  of  time  to  function,  but  a  closer  look  reveals  that 
the  number  of  channels  in  a  link  determines  how  fast  the  implemented  algorithm  will  run.  During 
request  message  propagation,  each  link  polls  its  channels  to  determine  if  it  can  accommodate  the 
circuit  request.  As  the  implemented  algorithm  executes  serially,  it  can  not  advance  until  all  the 
channels  in  the  link  have  replied.  Thus  PRP  executes  in  time  proportional  to  the  number  of 
channels  in  the  network  and  consumes  menrrary  space  based  on  the  number  of  channels  since 
each  channel  use  a  finite  amount  of  memory. 

In  the  TCA  version  of  the  saturation  routing  algorithm,  the  network  nodes  parallel  process 
request  messages  assisted  by  the  links  which  determine  channel-status  non-sequentially.  No 
longer  bound  by  the  constraints  of  depth  first  search,  the  parallel  processing  of  the  search 
messages  diminishes  link-quantity  as  a  determinant  of  execution  speed.  Purthermore,  if  channel 
status  inkjrmation  can  be  gathered  and  consolidated  kxlependent  of  request  message  use,  then 
channel  quantity  no  longer  dominates  the  algorithm’s  execution  time.  Thus  the  search  algorithm  in 
TCA  runs  In  time  0(n),  or  according  to  ttre  number  of  nodes. 
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ConclintoM 

PRP  represents  an  Initial  attempt  to  route  circuits  In  a  tactical  network  with  an  algorithm 
that  takes  into  account  real-world  constraints.  The  tact  that  this  can  be  done  on  a  limited  scale 
suggests  that  an  inexpensive  route  planner  could  be  developed  for  actual  use.  Even  more  so,  an 
inexpensive  rMro-flt  could  be  designed  fOr  existing  CNCEs,  offering  circuit  routing  flexibility  and 
freedom  from  contingency  plans  as  a  by-product 

Although  designed  for  paraliei  operation,  the  same  basic  tenets  of  message  passing,  cost 
determination,  and  channel  allocation  apply  equally  weU  to  PRP’s  sequential  execution  of  the 
algorithm.  Thus,  even  though  PRP  explores  nodes  in  an  order  different  than  TCA,  PRP  will 
produce  a  shortest  path  solution  as  would  TCA.  if  ail  the  route  planner  needs  is  a  few  good  routes 
to  choose  from,  then  PRP  will  provide  them,  albeit  slower  than  would  a  true  parallel  design,  but 
with  the  ability  exclude  damaged  components.  From  a  time  perspective,  PRP  searches  a  small 
n^ork  of  four  nodes,  five  links,  arxl  twenty  chanrteis  within  ten  seconds.  This  time  will  increase 
as  the  number  of  nodes,  links,  and  channels  in  particular,  increase. 

Channel  priority  encoding,  which  Is  pivotal  to  the  design  of  PRP,  would  play  an  even 
bigger  part  in  a  TCA  implementation.  It  ^so  requires  modifications  to  support  the  algorithm. 
Consider  a  request  message  that  enters  a  tactical  network  supported  by  TCA.  The  origin  node 
propagates  copies  of  the  message  across  every  connected  link,  but  before  doing  so  it  examines 
the  capability  of  the  link's  channels  to  support  the  message’s  priority.  Channel-status  buffers  at 
either  end  readily  provide  this  information  as  they  accumulate  the  priority  attributes  periodically, 
channel  by  channel,  by  polling  the  channel  directly.  The  key  Is  to  make  priority  Information 
avaflafale  bv  hiding  It  In  the  message  or  the  carrier  so  that  the  same  Information  appears 
throughout  the  network.  A  broken  circuit  can  not  pass  the  priority  code  to  the  channels  allocated 
to  It  so  those  channela  revert  to  spare  status  for  later  circuit  regeneration.  The  same  technique 
permits  rapid  cost  assessment  for  individuai  channels  and  larger  links. 
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A  CNCE  network  would  be  more  toierant  to  damage  and  easier  to  maintain  if  it 
incorporates  a  nKXlified  version  of  the  saturation  search  algorithm.  By  encoding  priority 
information  within  the  active  circuits  that  ride  the  network  and  e)(tracting  It  at  each  CNCE,  a 
computer  at  each  node  could  send,  pass,  pnd  receive  routing  messages  that  work  In  aggregate  to 
find  successful  circuit  routes  without  prior  ioxjwiedge  of  the  network’s  condition.  A  tactical 
network  that  Incorporates  this  algorithm  requires  no  pre-planned  back-up  routes  since  the 
algorithm  determines  the  best  route  based  on  existing  circuits  and  working  equipment,  while 
supplying  the  same  information  that  technical  controllers  use  now  to  maintain  circuits. 

Recommendations  for  Future  Work 

Although  the  PRP  shows  that  a  search  algorithm  can  be  adapted  for  use  in  a  tactical 
communications  network,  more  work  is  needed  to  accurately  model  CNCE  network  information. 
Several  possible  options  come  to  mind;  1)  Refine  PRP  object  components  so  that  they  accurately 
embody  the  detail  (bit  rates,  priority  codes,  etc.)  needed  to  layout  an  actual  tactical  network.  2) 
Translate  the  algorithm's  object  Implementation  Into  Ravors  for  Incorporation  into  QUS,  an 
existing  network  mapping  program  written  by  graduate  students  at  Clarkson  College  that  runs  on 
a  Symbolics  work  station.  3)  Write  a  mouse-based  network  drawing  system  like  GUS  that  "hooks" 
into  Scheme  and  converts  mouse  inputs  into  a  network  description  like  the  network  files  included 
in  appendix  B.  As  an  alternative,  one  could  rewrite  the  network  objects  in  C  +  +  or  Ada  to  take 
advantage  of  existing  graphics  routines. 

PRP  could  profit  by  a  system  that  stores  the  results  of  a  networking  session  for  later 
continued  analysis.  A  feature  like  this  stores  the  machine's  environment  in  a  file  for  storage,  easing 
later  recall  of  the  network's  transient  state.  Scheme  supports  this  concept,  but  PRP  does  not 
implement  network-capture  at  this  time. 

One  final  suggestion  for  further  research  lies  in  the  area  of  network  protocols.  If  circuit-ID 
and  priority  information  can  be  incorporated  kko  the  header  of  a  communications  protocol,  then 
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OiCEs  could  use  this  information  to  plan  routes  the  same  as  PRP.  The  challenge,  is  to  find  a  way 
to  insert  this  information  Into  existing  networks. 


Appendix  A: 
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The  Prototype  Route  Planner  (PRP)  helps  you  find  routes  for  prioritized  circuits  in  a 
tactical  network.  This  manual  tails  you  about  the  requirements  and  features  of  PRP  and  shows  you 
how  to  use  the  system  to  experiment  with  networks  of  your  own.  The  first  portion  of  the  manual 
(System  Requirements,  Creating  N^works,  Installation  and  Start-Up)  discusses  preparatory 
instmctions,  whPe  the  last  half  (Commands  and  Inspection  Tools),  covers  features  used  while 
running  PRP. 


System  Requirementa 

The  Prototype  Route  Planner  (PRP)  requires  an  IBM  compatible  computer  host,  and  PC 
Scheme  version  3.0  to  interpret  commands  and  draw  diagrams.  Furthermore,  PRP  needs  an  EGA 
color  graphics  display  and  works  best  on  computers  with  a  Winchester  (hard)  drive,  if  you  have 
the  above  configuration, (i.e.  Zenith  248  with  the  EGA  color  monitor)  the  program  will  work  as 
interxled. 


Creating  Networte 

Although  you  can  create  specific  Instances  of  nodes,  links,and  channels  via  keyboard 
commands  during  a  PRP  session,  a  network's  components  should  be  defined  prior  to  using 
PRP.Any  word  processor  that  writes  to  an  ASCII  file,  including  Scheme’s  text  editor,  wili  do  the 
Job.  Rrst,  retrieve  one  of  the  practice  networks  provided  with  PRP,  then  use  the  word  processor  to 
modify  the  nodes,links,  and  channels,  so  that  they  reflect  the  features  you  want  them  to  have.  If 
you  need  to  make  additionai  objects,  just  copy  a  simlar  ol^ect  arxl  update  its  name  and  instance 
variables  with  the  necessary  values.  As  you  create  objects  that  connect  to  each  other,  be  aware 
that  connections  are  bMateral;  that  Is,  a  rxxie  has  record  of  the  links  It  can  talk  to,  and  each  link 
completes  the  connection  by  including  that  node  in  its  instance  variable  NODES.  When  you  have 
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finished  making  and  connecting  the  network’s  components,  be  sure  to  save  your  network  under  a 
new  name  so  as  not  to  write  over  the  practice  network. 


InatalUtton 

This  section  tells  you  how  to  prepare  your  computer  to  run  PRP.  If  you  have  already 
installed  PC  Scheme  according  to  the  following  Instructions,  go  to  the  Stait-Up  section,  otherwise 
install  PC  Scheme  by  placing  the  distribution  disk  In  the  A:  drive,  then  follow  the  instailatton 
directions  In  chapter  2  of  the  Tl  Scheme  User's  Guide.  If  you  have  an  IBM  compatible  computer 
with  EGA  color  monitor  arxf  Wirrchester  disk  drive,  the  Installation  command  will  look  like; 

ArINSTALL  C:  \SCHEME  W 

where  \SCHEME  is  a  directory  created  by  the  installation  program  that  contains  all  Scheme 
executable  code,  and  W  irxficates  that  the  computer  has  a  Winchester  drive.  If  your  system  has 
only  floppy  disk  drives,  refer  to  chapter  2  the  User’s  Guide  for  installation  details.  Upon 
completion,  you  will  be  in  the  C:\SCHEME  directory. 

Start«Up 

This  section  tells  you  about  the  batch  command  that  starts  PRP.  Before  using  it  you  must 
know  that  It  changes  the  computer’s  path  to  read  from  the  hard  and  floppy  disk  drive.  In  this 
configuration,  all  PC  Scheme  code  is  accessed  from  the  C;  drive  while  all  PRP  code  is  accessed 
frorn  the  A;  drive.  After  setting  the  path,'the  batch  command  then  calls  PC  Scheme,  and 
automatically  loads  PRP  for  PC  Schema  to  krterprat.  To  start  PRP  make  A;  your  current  directory 
and  type: 

PRP 

The  initialization  process  takes  about  12  seconds  on  an  AT  class  machine.  When  it  completes,  you 
will  see  a  blank  screen  except  for  the  bottom  line  which  contains  the  command  prompt  [1  ] , 
followed  by  the  cursor  and  the  status  line.  All  commands  entered  from  the  keyboard  will  be 
echoed  at  the  prompt  Also,  PRP  returns  messages  to  you  via  the  prompt.  As  an  alternate  means 
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of  installation,  you  can  copy  the  contents  of  the  PflP  disk  to  Its  own  directory  on  the  C:  drive  and 
change  the  path  In  PRP.BAT  so  that  the  computer  can  find  this  new  directory.  This  alternate 
configuration  permits  faster  code  loedbig  since  at  code  is  read  from  the  Winchester  drive. 
Additionally,  It  frees  the  A:  drive  for  external  use.  However,  since  PC  Scheme  retains  all  loaded 
code  in  memory  and  does  not  free  memory  by  writing  to  disk,  this  alternate  installation  method  will 
not  Improve  execution  time. 

Loading  a  Metworh 

This  section  tells  you  how  to  load  a  network  into  PRP,  since  PRP  contains  no  network 
information  when  you  first  start  it  You  could  buHd  a  network  one  object  at  a  time  by  defining  them 
with  Scheme's  make-instance  command,  but  it  is  much  easier  to  load  a  pre-defined  network.  PRP 
comes  with  several  practice  networks  that  can  be  nxxJified  as  desired.  For  example,  to  load  the 
practice  network  STICK  type  the  command; 

(LOAD  "ST1CK.FSL") 

As  this  is  a  Scheme  operation,  parens  bracket  the  word  load,  arxJ  quotes  denote  the  file  name.  In 
the  above  example,  the  command  wilt  load  the  Stick  network  which  is  stored  in  a  fast-load  or  .fsl 
file  format  Fast-load  files  are  text  files  that  have  been  processed  for  quicker  loading.  PRP  can  also 
load  source  files  (.s  files),  but  these  fUes  take  longer  to  read.  Any  pre-defined  networks  you  create 
start  out  as  source  files  (and  should  have  an  S  extension).  These  hies  can  later  be  co;  .verted  to 
object  and  fastioad  files  at  your  discretion.  However,  unless  you  discover  a  network  worthy  of 
repeated  use,  source  files  are  the  easiest  to  read  arx)  manipulate.  The  word  OK  v/ill  appear  at  the 
prompt  if  the  fie  loads  normally.  If  instead  you  see  the  prompt  [Inspect],  then  PC  Scheme  has 
found  an  error.  Since  the  PRP  corrunand  line  is  only  orte  line  long,  you  wll  not  be  able  to  read  the 
diagnostic  message.  Type 

(NORMAL) 
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to  change  PRP  to  text  mode,  and  try  to  load  the  fie  agaia  This  tbne  you  will  be  able  to  read  the 
diagnostic  message.  Correct  any  errors  you  And  and  return  PRP  to  graphics  mode  by  entering 

(CLEAR) 

before  ioading  the  network  fie.  In  gene^.'use  this  screen  toggling  technique  any  time  you  bump 
into  operating  errors. 

ComilMIKlfl 

Four  commands,  Make-Circuk,  Pick-Route,  Dead  aixi  Alive  control  network  objects. 
Meke-CifcuB.  The  Make-Circuit  (MC)  command  starts  the  search  for  a  path  from  the 
initiating  node  to  the  destination  node.  The  command  includes  the  circuit’s  priority  in  the  form  of  a 
single  letter,  A  through  C,  and  the  starting  and  terminating  nodes,  referred  to  by  number.  For 
example, 

(MC  1  2  ’A) 

requests  an  A  priority  circuit  from  node  1  to  node  2.  Note  that  the  A  is  preceded  by  an  apostrophe. 

Pick-Route.  As  PRP  searches  for  routes,  it  occasionally  beeps  to  let  you  know  that  it 
found  a  good  path.  That  is  your  cue  to  use  the  Pick-Route  (PR)  command  on  the  destination  node 
when  the  search  activity  stops.  The  Pick-Route  command  lets  you  act  as  the  technical  controller 
of  a  CNCE.  For  example,  if  you  want  to  authorize  a  route  at  node  2  type 

(PR  2) 

PRP  wll  display  ail  reported  routes  for  the  first  circuit  in  node-2’s  buffer.  The  display  will  show  cost 
arxl  route  information  aixl  It  wll  ask  you  to  select  one  or  none  of  the  choices.  To  authorize  one  of 
the  routes,  simply  enter  its  corresponding  number  and  press  the  return  key.  When  you  do,  PRP 
wll  generate  a  reply  message  that  works  Its  way  back  along  the  route,  allocating  channels  to  the 
circuit  as  It  goes.  If  PRP  can  not  Arxl  a  suitable  channel  during  this  allocation  process,  it  wll  warn 
you  and  ask  that  you  pick  an  alternate  rotfie.  If  there  is  no  alternate,  the  circuit  can  nc^  be 
complete,  and  the  request  shoiid  be  re-inWated  from  the  originating  node.  If  there  is  more  than 
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one  circuit  in  the  node’s  buffer,  PRP  wl  display  the  second  set  of  routes  after  dispatching  the  first. 
This  process  continues  unti  the  buffer  is  empty.  If  you  mistakeniy  use  the  Pick-Route  command 
on  a  non- destination  node,  PRP  simply  replies  that  there  are  no  more  routes. 

QaadL  The  Dead  command  klls  an  object  or  a  list  of  objects.  It  does  this  by  changing 
the  object's  STATUS  instance  variable  from  ’ALIVE  to  ’DEAD.  Dead  objects,  drawn  in  gray,  do  not 
respond  to  inspection  questions  and  do  not  paftidpata  in  the  route  finding  process.  For  example, 
to  kfll  NOOE-1  type; 

(DEAOCNCE-1) 

MrAiple  objects  can  be  killed  as  in  the  foilo^ng  example: 

PEAO  (UST  CNCE-1  UNK-1  UNK-3  CHANNEL-12  ClRCUIT-9)) 

Alive.  The  Alive  command  rejuvenates  dead  ot^ects  by  changing  their  STATUS  instance 
variable  from  ‘DEAD  to  'ALIVE.  Living  objects  show  up  in  color  and  respond  when  queried.  The 
Alive  command  revives  single  or  multiple  objects  using  the  same  syntax  as  the  Dead  command 
above. 

Inspection  Tools 

The  inspection  tods  Nodes?,  Links?,  Channels?,  Circuits?,  Requests?,  Replies?,  and 
Look,  permit  you  to  ask  any  object  about  Its  relationship  with  other  objects.  In  other  words,  you 
can  ask  an  object  about  the  nodes,  links,  channels,  and  circuits  that  it  owns  and  you  can  directly 
inspect  the  REQUESTS  and  REPLIES  instance  variables  in  a  node.  Ail  inspection  tods,  with  the 
exception  of  Look,  end  with  a  question  mark  to  signify  that  they  ask  the  object  something.  Figure 
12  shows  how  each  class  of  objects  responds  to  questions  about  other  objects.  The  Look  tod 
differs  from  all  other  tods  in  that  it  can  not  be  used  by  itself.  Looks  reveals  the  name  of  each 
object  given  to  It  by  another  inspection  tod.  Without  Look,  ail  you  wH’  see  is  an  unintelligible 
machine  code  answer. 
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Figure  12.  Inspection  Tools 


Completion 

To  exit  a  PRP  session  first  reset  the  display  to  text  mode  by  typing 

(NORMAL) 


then  to  return  to  DOS  enter 


(EXIT). 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  1  September  1988  ■  . 

VERSION:  1.0 
TITLE:  Class  Declarations 
RLENAME:  class.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  Capt  G.R.  Gier 

CONTENTS 

CLASSES:  IDENTITY,  NODE.  UNK,  CHANNEL.  CIRCUIT 
METHODS:  living,  auto-connect-Circuit,  one-more 
COMMANDS:  none 
TOOLS:  none 
UTIUTIES:  none 
SYS/MACRO:  none 

CALLED  BY:  none 
CALLS:  none 

INPUTS:  New-Circuit,  Channel 
OUTPUTS:  none 

VARIABLES  USED:  Status,  Circuit.  Name 
VARIABLES  CHANGED:  Channels.  Status 
FILES  READ:  none 
FILES  WRITTEN:  none 


;*  FUNCTION: 

.* 

;*  Nodes,  links,  channels,  and  circuits  represent  the  four  major  classes  of 
;*  objects  in  this  environment.  An  additional  class  called  Identity  is  mixed 
;*  in  to  provide  an  initlable  name-value  upon  creation  and  a  status  value 
;*  (dead  or  alive)  that  can  change  during  program  execution.  In  the  ONCE 
;*  world,  a  strict  hierarchy  prevents  one  object  from  talking  to  any  other. 

;*  The  relationship  looks  like  this,  with  arrows  representing  communication 
;*  flow:  Node  <  — >  Link  <  — >  Channel  <  — >  Circuit. 

.**«*«**********«*****«***«**********************«****************************** 

t 


(define-dass  IDENTITY 
(instvars  Name 

(Status  ’Alive)) 

(options  (gettable-variables  Name') 
(settable-variables  Status) 
(Inittable-variables  Name))) 
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(deflne-method  (IDENTITY  living)  Q  ;D0tennines  if  the 

Of  (eq?  Status  ’Alive)  #T  #F))  ;object  wW  respond. 

(compae-dass  IDENTITY)  ;Emers  the  class  into  the  computer. 

(defins'dass  NODE 

(dassvars  (Population  0)) 

(mbdns  IDENTITY) 

(instvars  (Rectangle  (make-window  #F  #T)) 

(Serial-Number  (set!  Population  (1  +  Population))) 
Requests  :A  taUeof  request  messages. 

Replies  :A  table  of  reply  messages. 

Links)  ;A  list  of  links  that  node  owns. 

(options  (gettable-varfaLies  Requests  Replies  Links) 

(settable-variables  Requests  Replies  Links  Population))) 

(compBe-ciass  NODE) 

(define-dass  LINK 

(mbdns  IDENTITY) 

Onstvars  (Score-Board  (make-window  #F  #F)) 

Nodes  ;A  list  of  nodes  the  link  owns. 

Channels)  ;A  list  of  channels  the  link  owns. 

(options  gettade-variables 
settable-variables 
(inittable-variables  Nodes))) 

(compiledass  LINK) 

(definedass  CHANNEL 

(mixins  IDENTITY) 

(instvars  Link  ;The  link  that  owns  the  channel. 

(Circuit  (active  'Spare  #ff  aUo-connect-Circuit))) 

;The  circuit  al'located  to  the 
;channei,  or  'Spare  if  free. 

(options  gettabie-variades 
settable-variables 
(inittable-variables  Urik))) 

(define-method  (CHANNEL  auto-connect-Circult)  (New-CIrcuit) 

(if  (eq?  Circuit  ’Spare)  •  '.Check  if  a  spare  channel. 

(cond  ((eq?  New-Circult  'Spare)  ’Spare)  ;No  change, 
(else  ;Allocate  new  circuit. 

(send  New-Circuit  set-Channels  (eval  Name)) 
New-Circuit)) 

(cond  ((eq?  New-Circuit  ’Spare) 

(s^  Circuit  set-Status  ’Dead)  ;Remove  channel. 
’Spare)  ;Set  to  spare. 

(else 

(send  Circuit  set-Status  'Dead)  ^Remove  channel, 
(send  New-Circult  setChanneis  (eval  Name)) 
New-Circuit))))  .Allocate  new  circuit. 
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(compile-dass  CHANNEL) 


(deflne-dassaRCUrr 

(mbdns  IDENTITY) 

Onstvars  (Channeia  (active  *0  #F  one-more))  ;A  channel  list 
(Priority<k>st  (vector  000 1)})  ;Prk>^  vector, 
(options  gettabie-variables  ;fonn  #(  A  B  C  Spare), 

settable-variables 
inittable-varlables)) 

(deflne-mdhod  (CIRCUIT  one-more)  (Channel) 

(If  (member  Channel  Channels)  (deletel  Channel  Channels) 
(append  Channels  (list  Channel)))) 


(compOe-dass  CIRCUIT) 


********* 
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A******************************************************* 

PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  2  September  1988 
VERSION:  1.0 

TITLE:  Procedural  Methods  for  Relaying  Messages  in  Nodes 
RLENAME:  reiay.s 

OPER  SYS:  OOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

CONTENTS 
CLASSES:  Node 
METHODS:  relay-lt 
COMMANDS:  none 
TOOLS:  none 
UTILITIES:  none 
SYS/MACRO:  none 

CALLED  BY:  relay 

CALLS:  draw,  exclude,  iMng,  took,  relay,  sort-links, 
table-lookup,  tack-on,  v> 

INPUTS:  Message  .  . 

OUTPUTS:  Message 

VARIABLES  USED:  Requests 
VARIABLES  CHANGED:  Requests 
RLES  READ:  none 
FILES  WRITTEN:  none 


FUNCTION: 

The  node  version  of  Relay-lt  acts  as  a  main  program  in  that  it  determines 
which  subordinate  modules  to  call.  Relay-lt  first  checks  for  termination 
of  a  request  If  the  node  matches  the  message  destination,  it  checks  its 
Replies  table  for  previous  messages.  If  a  duplicate  exists,  Relay-it 
compares  the  cost  of  the  stored  message  with  that  of  the  new.  If  the  new 
route  costs  less,  It  is  incorporated  into  the  Replies  table  during  lookup, 
otherwise  It  Is  discarded.  Whether  a  first  time  message  or  a  cheaper, 
duplicat  message,  Relay-lt  beeps  signifying  success  without  halting 
subsequerS  message  passing.  Just  like  the  popping  of  popcorn,  you  check 
the  resiits  (using  pr)  when  the  noise  stops.  Furthermore,  if  you  wait  too 
long  the  product  bu^  as  subsequent  request  messages  fii^  the  Replies 
table. 

-continued- 


(deflne  Light-Magenta  61) 
(define  Magenta  5) 
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(deflne-method  (NODE  relay-it)  (Message) 

(draw  Ught-Magenla) 

(HOMng) 

(jet*  ((Cbcult-ID  0lst-ref  Message  0)) 

(Mode  (Ust-raf  Message  1)) 

(Destination  (eq?  Oiet-ref  Message  2)  Name)) 

(Priority  Obt-rsf  Message  3)) 

(Cost  Obt-rsf  Message  4)) 

(Path  0bt-ref  Message  5))  -  • 

(Origin  (eq?  Name  (car  (iast-pair  P«^)))) 

(Beep  (integer-char  7)))  ;AiJdio  aiert  message, 

(cond  ((eq?  Mode  ’request)  *,A  Request  message. 

Get*  ((Dup-Request  (table4ookup  ‘requests  Message)) 
;Tabie4.ookup  returns  dupiicate  message  or  ‘Q. 
(Previous-Cost  (Ibt-ref  Dup-Request  4)) 

.‘Cost  of  the  stored  message. 

(Lower-Cost  (v>  Previous-Cost  Cost)) 

;Retums  true  or  false. 

(From-Link  (cadr  Path)) 

;The  request  came  vb  thb  link. 

(Ordered-Unks 

(exclude  (eval  From-Unk)  (sort-iinks  Prkirity)))) 
ordered  list  of  which  link  to  talk  to. 

(cond  pestination  ‘.Terminate  message  if  the  destination. 
Oet*  (Pup-Re^y.Retums  stored  message  or  'Q- 
(table4ookup  'replies  Message)) 

(Cost-Paths  (car  (last-pair  Dup-Reply))) 

;((Cost-1  Path-1  )...{Cost-N  Path-N)). 
(PrevkMS-Cost  (caar  (l£^-pair  Cost-Paths))) 
;Cost-N. 

(Expensive-Route  (y>  .Cost  Previous-Cost))) 
;True  or  false. 

(writein  Name I  am  the  message  destination.") 

(K  Dup-Reply 
(if  Expensive-Route 
(begin 

(writein  Name Too  mpensive-"  Message) 
;Message  terminates. 

(draw  Magenta)) 

(begin 

(append!  Cost-Paths 
;Add  an  alternative  route  to  the  others. 

Obt  0bt  Cost  Path))) 

(writein  Name Include  an  alternate 

route-" 

Message) 

(draw  Magenta) 

(display  Beep)))  :Signai  success. 

(begin  0«rMn  Name New  route-"  Message) 
;Firat  time  message. 
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(draw  Mageitta) 

(display  Beep)))))  ;Slgnai  success. 

**>«<»>»«*«*»«  »«««*««**«*«**»««•*«***************«**** 

*  If  not  the  destination.  Reiay-lt  checks  if  it  has  previousiy  passed  the 

*  same  meesage.  If  a  lower  coat  duplicate  resides  hi  the  Requests 

*  table,  the  message  expires.  If  the  new  message  Is  cheaper,  Relay-lt 

*  replaMs  the  old  with  the  new  and  then  passes  the  new  message  on  to 

*  ail  IMng  links  except  the  one  that  delivered  the  message.  Beforethe 

*  link  harxi^howeimr,  Relay-lt  tacks  on  the  link’s  name  to  the  path  list 

*  If  Relay-it  can't  find  a  duplicate  request  meesage  9irst  time  message), 

*  it  annotates  Requests  via  Tabie-Lookup,  modifies  the  path  and  relays  the 

*  new  message  to  the  appropriate  links. 


;*  -conUnued- 


(Dup-Request 

.‘Trareient  message,  check  for  previous  passage. 

(writein  Name I  already  have  this  message.") 

(if  Lower-Cost 

;if  cheaper,  replace  old  message  and  retransmit. 

(begin 

(wrIteIn  Name Its  cheaper  so  keep  it") 

(set-cart  (member  Oup-Request  Requests)  Message) 

;Sm^  old  for  new. 

(writein  Name ";  Update  my  friends  “ 

(look  Ordered-Unks)) 

(draw  Magenta) 

(for-each  (lambda  (Link)  ;Update  links. 

(Relay  Link  (tack-on  Link  Message))) 

Oider^-Links)) 

(begin 

(draw  Magenta) 

(writein  Name ":  Message  too  expensive  to 

pass.")))) 

(else  ;Rrst  time  transitory  message. 

(writein  Name ":  I  have  a  new  message.") 

(writein  Name ":  Tell  my  frietxjs "  (look 
Ordered-Unks)) 

(draw  Magenta)  .  . 

(for-each  Oambda  (Link)  JeU  links. 

(Relay  Link  (tack-on  Link  Message))) 

Ordered-Unks))))) 

;*  If  Relay-lt  receives  a  Reply  message,  the  node  routes  the  message  to  the 
;*  next  link  In  the  Path  for  channel  allocation,  that  Is  unless  Relay-lt 
;*  corresponds  with  the  message  origin,  in  which  case  the  method  terminates. 

Note  that  the  back  link  is  to  the  right  of  the  Relay-lt  node,  which  is 
;*  one  link  closer  to  the  origin. 


) 


:*  Path:  (Destination  Dest-Side-Link  Relay-lt-Node  Origin-Side-Unk’  Origin) 


') 


((eq?  Mode ’reply)  ■  ' 

(M  ((Back-Link  (cadr  (mambar  Nama  Path)))) 

(cond  ((not  Origin) 

;Tanninata  Vtha  origin,  aisa  pass  maesaga. 
^vritain  Nama  *:  Paaa  raply  maasaga  to  * 

(look  Back-Link)) 

(draw  Magarta) 

(relay  (ewd  Back-Link)  Massage)) 

(else 

(draw  Magenta) 

(writein  "Attentlonl  *  Orcidt-ID  *  now  exits  via " 
Path))))) 


*  If  the  Ralay-lt  node  receives  a  Reject  message  and  It  is  also  the  message 

*  destinatioa  K  sounds  a  warning  be^,  signaling  the  tech  controller  to 

*  pick  a  new  route  using  PR.  If  not  the  destination,  the  node  relays  the 

*  message  to  the  destination  side  link. 


((eq?  Mode  ’reject) 

Oet  ((Previous-Link  (cadr  (member  Name  (reverse  Path)))) 
(Processad-Reply  (table-lookup  'replies  Message))) 
.‘Returns  stored  message  or  'Q. 

(cond  ((not  Oestination)  .Pass  the  message. 

(writein  Name Send  reject  message  to  ” 

(look  Previous-Link)) 

(draw  Magenta) 

(relay  (evai  Previous-Link)  Message)) 

(^se  ;Annotate  bad  route  and  warn. 

(IM*  ((Bad-Route-lnd»( 

(subi  Oist-ref  Processed-Reply  1))) 
(Cost-Paths 

(reverse  (car  (last-pak  Processed-Reply)))) 
:((Cost-l  Path-i)...(Cost-N  Path-N)). 
(Bad-Route 

(list-ref  Cost-Paths  Bad-Route-index))) 

(set-carl  (cdr  Processed-Reply)  ’0) 

(set-cart  Bad-Route  "—Bad—  *0 
(draw  Magenta) 

(do  ((n  0  (1  -»-  n)))  ;Triple  beep  warning  message. 

(( n  3)  (wikeln  Name Pick  a  new  route  for " 
Circuit-iO)) 

(display  Beep))))))))))) 


* 


END 


r««***«******«i 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  17  August  1988 
VERSION:  1.0 

TITtE:  Procsdural  Methods  (br  Rsiaying  Messages  in  Links 
RLENAME:  rsiay.s 

OPER  SYS:  DOS  VERSION  3.2  *  * 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

CONTENTS 
CLASSES:  Link 
METHODS:  relay-k 
COMMANDS:  none 
TOOLS:  none 
UTtUTIES:  none 
SYS/MACRO;  none 

CALLED  BY:  relay 

CALLS:  coord,  cost?,  draw,  living,  look,  relay,  select-channei 
table-lookup,  tack-on,  v> ,  v-f 

INPUTS:  Message 
OUTPUTS:  Message 

VARIABLES  USED:  Nodes,  Channels 
VARIABLES  CHANGED;  none 
RLES  READ:  none 

FILES  WRITTEN:  none  .  . 


FUNCTION: 

The  Link  version  of  Relay-lt  passes  messages,  examines  capacity,  and 
allocates  resources.  When  Relay-k  picks  up  a  Receive  message  and  its 
cost  justifies  preempting  a  channel,  then  Relay-lt  adds  that  cost 
to  the  message,  up^tes  the  path,  and  hands  the  information  over  to  the 
opposite  erxl  node.  Note,  no  allocation  takes  place  in  this  mode. 

-contlnued- 


) 


(define-mohod  (LINK  relay-k)  (Message) 
(If  (living) 

(let*  ((Circuk-IO  (list-ref  Message  0)) 
(»^e  0ist-ref  Message  1)) 

(Dest  0ist-ref  Message  2)) 
(Priority  (list-ref  Message  3)) 
(Old-C^  (list-ref  Message  4)) 
(Path  0i8t-ref  Message  5)) 
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(Origin-Side-Node  {wai  (cadr  (member  Name  Path)))) 
(Deat-SUe-Noda  (K  (eq?  Origin-Side-Node  (car  Nodes)) 

(cadr  Nodes) 

(car  Nodes))) 

(Choaen-Chaimai  (car  (soct-channeis))) 

(Preempt-Coat  (co^  Choeen-Channei)) 

(Orig-OxMd  (send  Origir>-Slde-Noda  coord)) 

(Dest-Coord  (sand  Oest-SUe-Node  coord))) 

(draw  'Ught-Qraen  Orlg<>)ord  Oeat-Coord  *0) 

(cond  ((eq?  Mode  ‘request) 

Of  (v>  Priority  Preempt-Coat)  ;Ched(  for  a  usable  channel. 
Oet*  ((New-Cost  (v-»-  OU  Old-Coat  Preempt-Cost))) 

;Up£tate  the  cost  of  using  the  channel. 
(New-Message  (append  Oiat  Ckcuit-iO) 

'.Reconstruct  the  message. 

Oist  Mode)*  * 

OistDest) 

(list  Priority) 

(list  New-Cost) 

Oist  Path)))) 

(writeln  Name  *:  I  have  an  allocatabie  channel-" 

Oook  Chosen-Channel)) 

(draw  ‘Green  Orig-Coord  Oest-Coord  (cost?  (eval  Name))) 
(relay  Oest-Side-Node  ;3erKi  updated  message. 

Oack-on  Oest-Side-Node  New-Message))) 

(begin 

(draw  'Green  Orig-Coord  Dest-Coord  (cost?  (evai  Name))) 
(writeln  Name I  dont  have  a  channel.")))) 


*  Allocation  takes  place  In  the  Reply  hkxIs,  providing  ChoservChannel  picks 

*  a  preemptable  channel.  If  not,  R^y-lt  changes  the  message  mode  to 

*  R^ect  and  reverses  path  direction  as  It  hands  back  the  message  to  the 

*  Issuing  node.  Relay-it  must  make  a  second  channel  check  since  other 

*  concurrent  messages  may  steal  the  resour^  between  the  initlai  request 

*  message  and  subsequent  allocatioaby.the  reply  message.  Successful 

*  allocation  means  the  channel  picks  up  a  new  circuit  (tuxi  kills  the  old 

*  circuit  If  necessary).  Likewise,  the  circuit  gathers  a  new  channel  into 

*  its  list  of  channels. 


((eq?  Mode  ‘reply) 

Oet  ((Distress-Message '(, Circuit-10 
Reject 

Message  2)))) 

(If  (v>  Priority  Preempt-Cost) 

'.Cant  find  a  channel  for  some  reason. 

(begin  (wrttein  Name  Allocate "  (look  Chosen-Channel) 
"to-CIrcull-iD) 

(send  ChoeenOrannel  set-Circuit  (eval  Circuit-ID)) 
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;Qlve  channel  cir&ilL 
(draw  'Rad 

Dast-Cooid  Ortg-Coord  (coat?  (aval  Name))) 
(relay  Or1gln-Slde^4ode  Meaaage)) 

;M)K.  pass  message. 

(begin  (wrkeln  Name  M  lost  my  chosen  channel.  Help!”) 
(dtaw'Green 

Orig-Coord  Dest-Coord  (cost?  (eval  Name))) 
(relay  Oest-SIde-Node  DIstrese-Mesaage))))) 

;0on1  allocate  and  pass  back  distress. 


A************************************************************************** 

*  When  Relay-lt  receives  a  Reject  message,  It  de-altocatas  Its  channel 

*  from  the  circuit  and  passes  the  Infbrmation  beck  towards  the  destination. 


((eq?  Mode  ’reject) 

Oet  ((UndoOvannei  (select-channel  Circuit-10  Channels))) 
(wiltein  Name Free "  (look  Undo-Channel)  ”.'') 

(send  Undo-Channel  set-Circuit  ’Spare)  ;Free  the  channel, 
(draw  ’Green  Orig-Coord  Oest-Co^  (cost?  (eval  Name))) 
(relay  Dest-SIde-Node  Message)))))))  ;Pass  the  message. 

(define  (relay  Object  Message)  ;Ger)erlc  function  for  calling  Relay-lt. 
(send  Object  relay-lt  Message))  ;Works  for  NODE  and  LINK  versions. 


END 


* 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


* 

*  DATE:  17  August  1988 

*  VERSION:  1.0 

*  TITLE:  Request-Table  and  Reply-Table  lookup  of  transiting  messages. 

*  RLENAME:tableJas 

*  •  • 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

*  AUTHOR:  CaptG.R.Gier 

* 

*  CONTENTS 

*  CLASSES:  NODE 

*  METHODS:  table-lookup 

*  COMMANDS:  none 

*  TOOLS:  none 

*  UTILITIES:  none 

*  SYS/MACRO:  none 

* 

*  CALLED  BY:  relay-it 

*  CALLS:  undup 

* 

*  INPUTS:  Mode,  Message 

*  OUTPUTS:  stored  Message  from  Request  or  Replies,  or  #F 

* 

*  VARIABLES  USED;  Requests.  Replies 

*  VARIABLES  CHANGED:  Requests.  Replies 

*  RLES  READ;  none 

*  RLES  WRITTEN:  none  •  - 

* 

*  FUNCTION: 

* 

*  This  method  services  a  node's  Requests  and  Replies  tables  when  called  on 

*  by  the  method  Relay-IL  Table-Lookup  (bracks  to  see  If  the  message  that 

*  was  passed  to  It  already  exists  in  the  appropriate  table  as  determined  by 

*  the  value  of  Modn.  1)  If  the  table  has  no  values  (first  message), 

*  Table-Lookup  enters  the  message  as  a  list  elem^.  2)  If  the  message 

*  does  not  match  any  existing  messages,  It  is  appended  to  the  end  of  the 

*  current  list  If  the  new  list  exceeds  five  messages  (arbitrary  length 

*  choice),  Table-Lookup  trims  the  oldest  message  efiectiveiy  creating  a 

*  RFO  stack.  In  both  the  empty  and  no-match  conditions,  Tabie-Lcokup 

*  returns  #F  as  its  value.  3)  If  Table-Lookup  flnds  a  message, 

*  it  returns  that  message.  Notice  Table-Lookup  modifies  the 

*  structure  of  messages  In  the  Replies  table.  This  modification  permits 

*  later  inclusion  of  alternative  path  routes  by  Circuit-ID. 


(define-method  (NODE  table-lookup)  (Mode  Message) 
Oet  ((Table  (evai  Mode))  ;'Reque8ts  or  'Replies. 


I 
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(Cbcult-IO  OM-raf  Message  0)) 

(Selection  ‘Q)  ;Place  holder  for  later  route  choice. 

(Dest  (|ist-ref  Message  2)) 

(Priority  dbt-rer  Message  3))  :Priorlty  vector. 

(Unique  0i8t4al  Message  4)))  .'(Cost  Path). 

(cond  ((eq?  Table  #IUNAS8iGNED)  ;Einpty  table. 

(ir(eq?  Mode ’Requests) 

(set!  Requests  Oist  Message))  :Uninodifled  message. 

(sed  Replies  (liat  Oist  Circuit-Id  ;Modlfled  message. 

Selection 

Oest 

Priority 

(list  Unique))))) 

#F)  '.Return  false. 

;Check  each  element  for  a  Circuit-10  match  and  return  if  found. 

;Undup  weeds  out  'Qs  and  Car  removes  extra  parens. 

((car  (undup  (mapcar  (lambda  QQ  (member  Circuit-ID  X))  Table)))) 

((eq?  Mode  ’Requests) 

(a|:^)end!  Requests  01^  Message))  '.Permanently  add  message. 
(If  ( >  (length  Table)  5)  ;Trim  if  too  long. 

(set!  Requests  (li^-taH  Table  1))) 

;Retum  false. 

((eq?  Mode  ’Replies) 

(appendl  Repli^  (11^  (list  Circuit-fO  ;Permanently  add 
Selection  ;modified  message. 

Oest 

Priority 

(list  Unique)))) 

(if  ( >  (length  Table)  5)  ;Trim  if  too  iong. 

(set!  Replies  (list-tal  Table  1))) 

#F))))  :Rrtum  false. 


END 


* 


******************************************************** 
PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  24  August  1988 
VERSION:  1.0 

TITLE:  Link  and  channel  sort  routines 
RLENAME:  sorts 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Studwit  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gler 

CONTENTS 

CLASSES:  UNK,  NODE 
METHODS;  sort-channels,  sort-links 
COMMANDS:  none 
TOOLS:  none 

UTILITIES:  examine-link,  useable 
SYS/MACRO:  none 

CALLED  BY:  relay-lt 

CALLS:  cost?,  examine-link,  living,' preempt +  ,  useabie,  v> 
INPUTS:  Priority 

OUTPUTS:  A  channel  list;  A  iink  list 

VARIABLES  USED:  Channels,  Unks 
VARIABLES  CHANGED:  none 
RLES  READ;  none 
RLES  WRITTEN;  none 


FUNCTION: 

This  module  contains  methods  for  the  Node  and  Link  class  of  objects. 

Although  the  code  in  each  Is  nearly  identicai,  the  results  of  calling 
either  method  are  different  erKXigh  to  warrant  unique  names  for  the 
sort  function.  Sort-Links  does  what  Its  name  Implies,  It  orders  the 
links  that  a  node  owns  so  that  the  first  Ikik  in  the  returned  list  is  the 
link  with  the  greatest  amount  of  usable  resources.  The  remaining  links 
have  decreasingiy  fewer  resources.  If  sort-link  is  passed  a  dead  link, 
or  one  that  can’t  horxir  a  channel  requesL  k  excludes  it  from  the  list. 

This  sort  process,  or  heuristic,  says  the  link  with  greatest  reserve 
is  the  one  wkh  the  best  chance  of  successfully  completing  a  circuit. 

Sort-Channels  also  does  what  its  name  says.  It  rank-orders  channels  so 
that  spare  channels  head  the  lisL  fokowed  by  C-ptiorlty,  B-prIority, 

A-priority,  and  lastly  dead  channels.  Sort-Channels  embodies  a  second 
heuristic  which  says,  allocate  spare  resources  flrsL  and  then  preempt 
low  priority  channels  before  high  priority  channels. 

r******************«****«*******«********************************************* 
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(define-msthod  (LINK  sort-channels)  0 
(if  (living) 

(let  (^airs  (mapcar  (lambda  (Channel)  ;Pair  a  channel 
(list  :to  Its  cost 
(preempt  +  (cost?  Channel)) 

Channel)) 

Channels))) 

(mapcar  cadr  (sort!  Pairs  v>)))))  .Sort  by  cost  and 
;retum  clumnei  list 

(define-method  (NODE  sort-links)  (Priority)  .Returns  an  ordered  list  of  links 
^  (if  (llviixi)  ‘.acceptable  for  message  priority. 

(let  ((Pairs  (examine4ink  Priority  Links))) 

(mapcar  cadr  (sort!  Pairs  v>)))))  :S^  by  capacity. 

(define  (examine-link  Priority  Links)  ‘.Returns  a  list  of  pairs. 

(if  (null?  Links)  nl  ;(capacity-vector  link) 

Oot*  ((Praempt-Cost  (preempt  +  (cost?  (car  Links)))) 

(Valid  (useable  Priority  Preempt-Cost))) 

(if  Valid 

(append  '((.Valid  .(car  Links))) 

(examine-IInk  Priority  (cdr  Links))) 

(examine-link  Priority  (cdr  Links)))))) 

(define  (useable  Priority  Preempt-Cost)  ;Oetermines  how  many  channels 
(do  ((Result  (vectorOOOO))  .can  satisfy  a  given  priority 
(Done  #F)  :and  returns  that  number. 

(Index  1  (1  +  Index))) 

(( >  Index  3)  (if  Done  Result)) 

(let  ((Supply  (vector-ref  Preempt-Cost  Index)) 

^  (Dernarid  (vector-ref  Priority  (subi  Index)))) 

(if  Done  (vector-set!  Result  Index  Supply) 

(if  (po^ive?  Demand) 

(H  (>  -  Supply  Demand) 

(begin 

(vector-setl  Result  Index  Supply) 

(setlDone#!)))))))) 

.*****«***«*«*******«***«****«**************•**********«************************ 
•*  * 

END  * 

•*  * 

.*******«*******««******«**«*«•*«*«*****«****#*«**«***************************** 
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****************************************************************************** 

*  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

* 

*  DATE:  23  August  1988 

*  VERSION:  1.0 

*  TITLE:  Make-CIrcult  command 

*  FILENAME:  mc.s 

* 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Schema  (Ver  3.0  Student  Edition)  w/SCOOPS 

*  AUTHOR:  Capt  G.R.  Gier 

* 

*  CONTENTS 

*  CLASSES:  none 

*  METHODS:  none 

*  COMMANDS:  me 

*  TOOLS:  none 

*  UTIUTIES:  none 

*  SYS/MACRO:  none 

* 

*  CALLED  BY:  User 

*  CALLS:  relay 

* 

*  INPUTS:  Keyboard  entry 

*  OUTPUTS:  Message  to  origin  node 

*  VARIABLES  USED:  *Clrcuit-ID* 

*  VARIABLES  CHANGED:  *Circuit-ID* 

*  FILES  READ:  none 

*  FILES  WRITTEN:  none 

* 

* 

*  FUNCTION: 

* 

*  The  Make  Circuit  command  takes  the  form:  (me  Origin  Destination  Priority) 

*  where  Origin  and  Destination  are  numbers  that  identify  a  CNCE  by  its 

*  suffix  (the  "1"  in  CNCE-1),  and  Priority  Is  either  ’a,  'b,  or  'c.  This 

*  command  creates  a  message  that  has  a  unique  Circuit  ID  as  its  head.  The 

*  message  is  a  list  of  symbols  and  vectors  with  the  following  format: 

* 

*  (Circuit'ID  ‘Reply  Destination  Prior-Vec  Cost-Vec  (Origin)) 

* 

*  Prior-Vec  Is  the  vector  form  of  Priority,  Priority ‘a  translates  to 

*  #(10  0  0);  ‘b,  #(0  1  0  0):  and  ‘c.  #(0  0 1  0).  Cost-Vec  Is  the  nul 

*  vector  #(0  0  0  0)  since  the  circuit  has  yet  to  accumulate  expenses  for 

*  traveling  links.  MC  passes  the  message  to  the  origin  node  for  subsequent 

*  re-transmission. 

* 

******************************************************************************* 


(define  (me  1  st  2nd  3rd)  Q 

(let  ((Origin  (string-  >  symbol  ;"CNCE-"  prefix  for  origin. 
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(string-append 'CNCE-” 

(number- >sMng  1st  ’(Int))))) 

(Circutt-IO  (strir^>  symbol 
(string-append 
"CIRCUIT-"  (number- >  string 

(sell  *Clrcult-ID*  (1  -i-  *Clrcult-ID*)) 

■(W))))) 

(Mode  'request)  ;Oetermlnes  how  Relay  treats  message. 

(Dest  (string- >  symbol 

(string-append  "CNCE-"  (number- >  string  2nd  ’(int))))) 
(Priority  (case  3rd  ;Lett«'  to  vector. 

((a)  (vector  10  0  0)) 

((b)  (vectorOI  00)) 

((c)  (vector  0  0 1  0)))) 

(Cost  (vector  0  0  0  0)))  ;Null  vector. 

(relay  (e\^  Origin)  ;Re^nsmit  message. 

Oist  Circuit-10  Mode  Oest  Priority  Cost  (list  Origin)))) 

"Message  request  sent.") 


END 


>««*«*************************•**************************************•********** 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  21  August  1988 
VERSION:  1.0  .  . 

TITLE:  Pick-Route  command 
RLENAME:  pr.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  pr 
TOOLS;  none 

UTILITIES:  pick-route,  present 
SYS/MACRO:  none 

CALLED  BY:  User 
CALLS:  pick-route,  present,  relay 

INPUTS;  Keyboard 
OUTPUTS;  Message 

VARIABLES  USED:  Replies 
VARIABLES  CHANGED:  Replies,  Name,*  Priority-Cost 
RLES  READ;  none 
RLES  WRITTEN;  none 


FUNCTION; 

The  command  Pick  Route  permits  the  technical  controller  at  the  destination 
node  to  choose  the  appropriate  route  for  implementation.  Pick  Route 
displays  all  unresolved  requests  one  at  a  time,  prompting  for  the  route 
choice.  Upon  selection,  PR  generates  a  Reply  message  for  execution 
by  the  destination  node  and  displays  the  next  unresolved  request  if  there 
is  one.  This  command  can  also  be  used  to  select  an  alternative  route  if 
the  first  choice  is  rejected.  The  controller  has  a 
choice  of  the  lowest  cost  route,  its  equivalent  cost  alternates,  and 
high  cost  routes  that  are  the  first  to  reach  the  destination.  In  other 
words,  the  quantity  of  routes  will  vary,  but  the  cheapest  will  always 
fill  the  number  one  position. 


(define  menu  (make-window  "Pick  Route"  #T)) 
(window-set-positioni  menu  4  IS) 
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(window-set-8izel  menu  17  SO) 


(define  (pr  Node-Number)  ;Format:  (pr  1). 

(let*  ((Node  (eval 

(string- >  symbol 
(string-append 

"CNCE-"  (number- >  string  Node-Number  ’Ont)))))) 

(Repiy-Tabie  (send  Node  get-Repiies))) 

(for-each  pick-route  Reply-Table))  ;Sequentialty  display  unresolved  routes 
"No  more  requests.") 

(define  (pick-route  Route-Choices) 

(let*  ((Circuit-ID  (car  Route-Choices)) 

(Picked  (cadr  Route-Choices)) 

(Dest  (caddr  Route-Choices)) 

(Priority  (cadddr  Route-Choices)) 

(Pairs  (reverse  (jist-ref  Route-Choices  4))) 

(Max  (length  Pairs))) 

(co^  ((not  Picked)  ;Unresoived  route. 

(window-popup  menu) 

(display  "This  is "  menu) 

(display  Oest  menu) 

(display "  responding  to  new  circuit  requests."  menu) 

(display  #\newline  menu) 

(display  #\newline  menu) 

(display  "Possible  routes  for. "  menu) 

(display  Circuit-10  menu) 

(display  #\newiine  menu) 

(display  #\newline  menu) 

(display "  Number  Cost  Route"  menu)  ;Header  information. 

(setl  Picked  (present  1  Pairs)) 

;List  alternatives  and  return  the  choice. 

(cond  ((eq?  Picked  ’a) 

(wirxiow-popup-deiete  menu))  *  ;Abort. 

((>  Picked  Max)  (pick-route  Route-Choices))  .Erroneous  entry, 
(else 

(set-car!  (member  'Q  Route-Choices)  Picked);Remember  choice, 
(eval  ‘(dafine , Circuit-10 

(make-instance  CIRCUIT 
'Name  ',Orcult-IO 
'Priority-Cost  .Priority))) 

;Create  new  circuit, 
(window-popup-delete  menu) 

(relay  (eval  Dest) 

(li^  Circuit-ID  'Reply  Oest  Priority 

;BuHd  reply  message. 

(car  (list-ref  Pairs  (subi  Picked))) 

;Subtiact  one  slnc^  0  represents  the  first. 

(cadr  (list-ref  Pairs  (subi  Picked))))))))))) 

(define  (present  index  Pairs)  ;A  utlity  to  display  cost-path  pairs. 
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(cond  ((null?  Pairs) 

(display  #\n0^lne  menu) 

(display  #\newline  menu) 

(display  ‘€nter  route  number  or  A  to  abort"  menu) 
(read))  ;Read  route  number  choice. 

(else 

(display  #\newline  menu) 

(display "  "  menu) 

(display  Index  menu) 

(display menu) 

(display  #\tab  menu) 

(display  (caar  Pairs)  menu) 

(display"  "menu) 

(display  (cadar  PsJrs)  menu) 

(present  (1  +  Index)  (cdr  Pairs))))) 


****** 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  17  August  1988  .  . 

VERSION:  1.0 

TITLE:  The  IHe  and  death  of  objects 
RLENAME:  llfe.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gler 

CONTENTS 
CLASSES,  none 
METHODS:  none 
COMMANDS:  dead,  alive 
TOOLS:  living? 

UTILITIES:  none 
SYS/MACRO:  none 

CALLED  BY:  User 
CALLS:  none 

INPUTS:  Object 
OUTPUTS:  Status  Information 

VARIABLES  USED:  Status 
VARIABLES  CHANGED;  Status 
FILES  READ:  none 
FILES  WRITTEN:  none 


FUNCTION: 

This  module  contains  three  commands  used  to  check,  and  set  the  behavior 
of  nodes,  links,  channels,  and  circuits.  If  you  ask  an  object  if  it  is 
living,  It  will  reply  with  'dead  or  'alive.  The  second  command,  dead, 
will  "make  dead"  a  single  object  or  every  object  given  to  it  in  list 
form.  Similarly,  the  last  commarxi,  alive,  undoes  the  dead  command. 
Objects  enter  the  environment  alive,  upon  instantiation. 


(define  (jiving?  Object) 

(send  Object  llviiig)) 

(define  (dead  Objects) 

(If  (atom?  Objects)  '  ' 

(send  Objects  set-status  'dead) 

(mapcar  (lambda  (Object)  (send  Object  set-status  'Dead))  Objects))) 
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(d^ine  (alive  Objects) 

(if  (atom?  Objects) 

(send  Ot^ects  set-status  ’Alive) 

(mapcar  (lambda  (Object)  (send  Ot^ect  set-status  ’Alive))  Objects))) 
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**********«*«**************w************************************************* 

PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  17  August 
VERSION:  1.0 

TITIJE:  Channel  ownership  Inspection  tool 
RLENAME:  channels.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

CONTENTS 
CLASSES: none 
METHODS:  cwns-channels 
COMMANDS:  none 
TOOLS:  channels? 
unUTIES:  none  .  . 

SYS/MACRO;  none 

CALLED  BY:  User 
CALLS:  flatten,  living,  undup, 

INPUTS:  Ob|ect 

OUTPUTS:  Machine  representation  of  obects  or  nii. 

VARIABLES  USED:  Unks,  Channels 
VARIABLES  CHANGED:  none 
FILES  READ:  none 
FILES  WRITTEN:  none 


FUNCTION: 

Nodes,  links,  circuits,  and  even  channels  can  reply  with  a  list  of 
channels  that  they  own.  The  method  call  in  each  case  is  owns-channels. 
If  you  ask  a  channel  if  it  owns  itself,  it  will  reply  with  an  environment 
representation  If  the  mix-in  instance  variable  Status  is  set  to  'Alive. 

If  Status  is  'Dead,  the  response  is  'Q.  The  function  "channels?"  applies 
to  all  four  classes  of  objects  and  simplifies  the  query  process.  For 
example  "(channels?  CNCE-1)"  returns  a  list  of  living  channels. 


(define-method  (NODE  owns-channels)  0 
(if  (living) 

(undup 

(flatten  (mapcar  channels?  Links))))) 

(define-method  (LINK  owns-channels)  0 
(if  Giving) 
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(undup 

(mapcar  channels?  Channels)))) 

(deflnenmthod  (CHANNEL  OMns-channeis)  0 
(K  (aval  Nante))) 

(define-method  (CIRCUIT  owns-channels)  0 
(irOMng) 

(undup 

(mapcar  channels?  Channels)))) 

(define-method  (NODE  cwns-channels)  Q 
(HOK/ing) 

(undup 

(flatten  (mapcar  channels?  Links))))) 


(define  (channels?  Object) 
(send  Object  cwrts-channeis)) 


.**«««**«*««*«**«*******************************tk******************************* 


r***************«******«*******«*««********i 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  16  August  1988 
VERSION:  1.0 

TITLE:  Circuit  ownership  inspection  tool 
FILENAME:  circuits.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  owns-circuits 
COMMANDS:  none 
TOOLS:  circuits? 

UTILITIES:  none 
SYS/MACRO:  none 

CALLED  BY:  User 
CALLS:  flatten,  living,  undup 

INPUTS:  Object 

OUTPUTS:  ktachine  representation  of  obects  or  nil. 

VARIABLES  USED:  Unks,  Channels,  Circuit 
VARIABLES  CHANGED:  none 
RLES  READ:  none 
RL£S  WRITTEN:  none 


FUNCTION: 

Nodes,  links,  channels,  and  even  ckcutts  can  reply  with  a  list  of 
clrcutts  that  they  own.  The  method  call  in  each  case  is  owns-circuits. 
If  you  ask  a  circuit  if  it  owns  itself,  it  w3l  reply  with  an  environment 
representation  if  the  mix-in  instance  variaUe  Status  is  set  to  'Alive. 

If  Status  is  'Dead,  the  response  is  '0-  'Hio  function  "circuits?"  applies 
to  ail  four  classes  of  objects  and  simpiifles  the  query  process.  For 
example  "(circuits?  CNCE-1)"  returns  a  list  of  living  circuits  that 
transit  CNCE-1. 


(define-m^hod  (NODE  owns-circuits)  Q 
(if  (living) 

(undup 

(flatten 

(mapcar  circuits?  Links))))) 
(define-method  (LINK  owns-circuits)  0 
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OrOMno) 

(undup 

(mapcar  drcuks?  Channels)))) 

(definennethod  (CHANNEL  owns-circults)  0 
(IfdMng) 

^  (symbol?  Circuit) 

Circuit 

(circuits?  Circuit)))) 

(define-method  (CIRCUIT  owns-circuits)  0 
(if  (living)  (eval  Name))) 

(define  (circuits?  Object) 

(If  (symbol?  Object)  Object 
(send  Object  owns-drcuits))) 

.«*****«********«***«*«*************«******************<************************* 
.*  * 

;*  END 

•*  * 


.******«*«**«**««***«***«*«**««***«**********************«********************** 


^♦♦♦♦••♦•******« ************************************************* 

PROTOTYPE  ROUTE  PLW4NER  FOR  ZENITH  248 

DATE:  16  August  1988 
VERSION:  1.0 

TITLE:  How  to  find  the  cost  of  links  and  channels 
FILENAME:  costs 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptQ.R.Gier 

CONTENTS 
CLASSES:  none 
METHODS:  cost-vector 
COMMANDS:  none 
TOOLS:  cost? 

UnUTIES:  none 
SYS/MACRO:  none 

CALLED  BY:  Keytxiard.  relay,  sort 
CALLS:  living,  v+ 

INPUTS:  Object  .  - 

OUTPUTS:  Four  element  vector  of  numbers  representing  cost  by  priority 

VARIABLES  USED:  Qrcuit,  Channels 
VARIABLES  CHANGED:  none 
RLES  READ:  none 
RLES  WRITTEN:  none 


FUNCTION: 

This  module  contains  the  code  that  determines  vector  cost  of  a  specific 
channel  or  link.  If  a  chanriei  is  free,  the  'Spare  value  will  cause  a 
value  of  #(0  0  0 1 )  to  be  returned  depicting  one  spare  in  the  format 
#(A  B  C  Spare).  If  a  channel  owns  a  circuit,  the  cost  of  preemptively 
using  the  chan^  is  the  priority  of  die  currently  assigned  circuit.  If 
the  channel  is  dead  it  r^ums  a  vector  nil,  #(0  0  0  0).  The  cost  of 
using  a  link  is  the  vector  sum  of  the  costs  of  channels  it  owns.  A  dead 
link  returns  a  vector  nl,  meaning  it  can  not  carry  circuits. 


******* 


(define-method  (CHANNEL  cost-vector)  0 
(if  (living) 

(If  (symbol?  Circuit) 

(vectorOO0 1) 

(if  (circuits?  Circuit) 

(send  Circuit  get-Priority-Cost) 
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(vectorOO0 1))) 

(vectorOOOO))) 

(define  (cost?  Object) 

(send  Object  cost-vector)) 

(define-method  (LINK  cost-vector)  0 
(if  (living) 

(v-f  ';vector  summation 

(mapcar  cost?  Channels)) 

(vectorOOOO))) 


END 
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.**************«*«*******«**«*******4k*****«************************************ 

:•  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

•  * 

;*  DATE:  16  August  1988 
;*  VERSION:  1.0 

;*  TITLE:  Link  ownership  Inspection  tool 
RLENAME:  llnks.s 

;*  OPER  SYS:  DOS  VERSION  3.2 

;*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

;*  AUTHOR:  Capt  G.R.  Gler 
•  * 

CONTENTS 
;*  CLASSES:  none 
;*  METHODS:  owns-IInks 
;*  COMMANDS:  none  *  - 

;*  TOOLS:  links? 

;*  UnUTIES:  none 

;*  SYS/MACRO:  none 

.* 

:*  CALLED  BY;  User 

;*  CALLS:  living,  undup 

.* 

;*  INPUTS;  Object 

;*  OUTPUTS:  ^tochine  representation  of  objects  or  nil. 

.« 

;*  VARIABLES  USED:  Unks,  Channels 
;*  VARIABLES  CHANGED:  none 
;•  FILES  READ;  none 
;*  FILES  WRITTEN;  none 

.* 

:*  FUNCTIC  iM: 

;*  Nodes,  channels,  circuits,  and  even  links  can  reply  with  a  list  of 
;*  links  that  they  own.  The  method  call  in  each  case  is  owns-links. 

;*  If  you  ask  a  link  If  it  owns  Itself,  it  will  reply  with  an  environment 
;*  representation  If  the  mix-in  instance  variable  Status  is  set  to  'Alive. 

;*  If  Status  is 'Dead,  the  response  is 'Q.  The  function  "links?"  applies 
;*  to  ail  four  classes  of  objects  and  simplifies  the  query  process.  For 
;*  example  "(links?  CNCE-1)"  returns  a  list  of  living  links  that  terminate 
;*  at  CNCE-1. 

.* 

.*************«******«*****«***********************«***************«*•****«*«*** 


(define-method  (NODE  owns-links)  0 
(if  (living) 

(undup 

(mapcar  links?  Links)))) 
f  (define-method  (UNK  owns-links)  Q 
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(V  giving)  (aval  Name))) 

(deflne-method  (CHANNEL  owns-links)  Q 
(K  (living) 

(links?  Link))) 

(deflne-method  (CIRCUIT  owns-links)  0 
(if  (living) 

(undup 

(mapcar  links?  Channels)))) 

(define  (Ibiks?  Object) 

(send  Object  owis-IInks)) 


END 
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****«*********«****«***«***«*********«*«**************************^ 

•  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

•  DATE:  17  August  1968 

•  VERSION:  1.0 

•  Tm^:  Machine  code  to  proper  name  conversion  tool 

•  RLENAME:  look.s 

•  OPER  SYS:  DOS  VERSION  3.2 

•  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

•  AUTHOR:  CaptG.R.Gier 

•CONTENTS 

•  CLASSES:  none 

•  METHODS:  none 

•  COMMANDS:  none 

•  TOOLS:  look 

•  l/nLJTIES:  none 

•  SYS/MACRO:  none 

•  CALLED  BY:  Keytioard,  relay-it 

•  CALLS:  none 

•  INPUTS:  Objects 

•  OUTPUTS:  A  single  name  or  a  list  of  object  names 

•  VARIABLES  USED:  Name 

•  VARIABLES  CHANGED:  none 

•  RLES  READ:  none 

•  RLES  WRITTEN:  none  •  - 

•  FUNCTION: 

•  This  tool  permits  the  user  to  read  the  names  of  objects  that  are  in 

•  "environmenr  format  Use  look  in  conjunction  with  other  tools.  For 

•  example,  if  you  want  to  know  which  links  CNCE-1  owns,  you  would  enter; 

•  0ook  Oinks?  CNCE-1)) 

•  The  reply  woukj  appear  something  like: 

•  (UNK-1  UNK-4  UNK-5) 

•  Look  filters  out  dead  objects  so  the  number  of  objects  returned  for 

•  inspection,  may  not  represent  the  number  of  objects  in  the  original  list 


(define  (look  Objects) 

(cond  ((nuH?  Objects)  nl)  ;A  dead  object  appears  as 'Q. 

((symbol?  Objects)  Objects)  ;Permit8  'Spare  to  be  returned, 

((atom?  Objects)  (send  Objects  get-name))  ;Reti1eve  object’s  name, 
(else  (mapcar  look  Objects))))  ;Oead  objects  don't  show  in  list. 
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)*****«********************************1 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  17  August  1988 
VERSION:  1.0 

TITLE:  Node  aemershlp  inspection  tool 
FILENAME:  node.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edttlon)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gler 

CONTENTS 
CLASSES:  none 
METHODS:  owns-nodes 
COMMANDS:  none 
TOOLS:  nodes? 

UnUTIES:  none 
SYS/MACRO:  none 

CALLED  BY:  User 
CALLS:  flatten,  living,  undup 

INPUTS:  Object 

OUTPUTS:  Ktachine  representation  of  objects  or  nil. 

VARIABLES  USED:  Channels,  Unk,  Name,  Nodes 
VARIABLES  CHANGED:  none 
RLES  READ:  none 
FILES  WRITTEN:  none 


FUNCTION: 

Channels,  links,  circuits,  and  even  nodes  can  reply  with  a  list  of 
nodes  that  they  owa  The  method  call  in  each  case  is  owns-nodes. 

If  you  ask  a  node  I K  owns  Kaeif,  It  vi4l  reply  with  an  environment 
represeraadon  K  w  mbc-ln  InstarKe  variable  Status  is  set  to  ’Alive. 

If  Status  is  *000(1.  the  response  Is  'O-  The  function  "nodes?”  applies 
to  al  four  daases  of  objoM  and  simplifies  the  query  process.  For 
example  "(raxlee?  UNK-1)"  returns  a  list  of  IMng  nodes  connected  to 
UNK-1. 


(defineHrnethod  (NODE  owns-nodes)  0 
(V  (INing)  (eval  Name))) 

(define-method  (LINK  owns-nodes)  0 
(IfOWng) 

(undup 

(mapcar  nodes?  Nodes)))) 


(define^nethod  (CHANNEL  ownswxxies)  0 
(ifOivina) 

(undup 

(nodes?  Unk)))) 

(define-method  (CIRCUIT  owns-nodes)  0 
(V  Giving) 

(undup 

(flatten 

(mapcar  nodes?  Channels))))) 

(define  (nodes?  Ot^ect) 

(send  Object  owns-nodes)) 


END 


92 


r 


**•*•«*«*«**«•«**«**«************************••************•****' 
PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  17  August  1988 
VERSION:  1.0 

TITLE:  Reply  table  Inspection  tool 
RLENAME:  teplies.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  replies? 

UTILITIES:  none 
SYS/MACRO:  none 

CALLED  BY:  User 

CALLS:  display-replies,  display-pairs 
INPUTS:  Node 

OUTPUTS:  Formatted  contents  of  the  Replies  Table. 

VARIABLES  USED:  Replies 
VARIABLES  CHANGED;  none 

RLES  READ:  none  '  * 

RLES  WRITTEN:  none 

FUNCTION: 

Replies?  Is  an  inspection  tool  that  displays  the  request  messages  owned 
by  a  node  in  an  easy  to  read  format  The  node  reply  table  retains  its 
o^inal  internal  form  as  Replies?  Is  not  destructive. 


(define  (replies?  Node) 

(for-each  display-replies  (send  Node  get-Repiies)))  ;Gets  reply  table. 

(define  (display-replies  Message)  .Prepare  banner 

(wrltehi)  ;and  common  info. 

(wrlteln  (car  Message) "  ”  (cadr  Message)  ”  *  (caddr  Message)  ”  " 
(cadddr  Message)) 

(for-each  display-pairs  (jist-ref  Message  4)))  ;Dispiay  cost  &  path, 
(define  (display-pairs  Pair) 

(wrlteln  #\tab  (car  Pair) " "  (cadr  Pair)))  ;indent  for  aH  routes 


*  END 

*  .  .  * 
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••A*************************************************************************** 

*  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

*  DATE:  17  Au(^  1988 

*  VERSION:  1.0 

*  TITLE:  Request  table  Inspection  tool 

*  RLENAME:  requests.s 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

*  AUTHOR:  CaptG.R.Gier 

*  CONTENTS 

*  CLASSES:  none 

*  METHODS:  none 

*  COMMANDS:  none 

*  TOOLS:  requests? 

*  UTILITIES:  dls^ 

*  SYS/MACRO:  none 

*  CALLED  BY:  User 

*  CALLS:  dis-req 

*  INPlfrS:Node 

*  OUTPUTS:  Formatted  contents  of  Requests  Table 

*  VARIABLES  USED:  Requests 

*  VARIABLES  CHANGED:  none 

*  RLES  READ:  none 

*  RLES  WRITTEN:  none 

*  FUNCTION: 

*  This  inspection  tool  displays  messages  in  a  node’s  request  table,  In  an 

*  easy  to  read  format  As  a  message  enters  the  request  table,  it  goes  to 

*  the  etxl  of  the  list 


(define  (requests?  Node) 

(for-each  dis-req  (send  Node  get-Requests))) 

(define  (dis-req  Message) 

(wrttein) 

(writein  (car  Message) "  "  (cadr  Message) "  "  (caddr  Message) "  " 


(cadddr  Message) "  ''  (llst-ref  Message  4)) 

(wrilefo  #\tab  Oist-ref  Message  5)))  ;indent  the  path. 
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.*«*****««#*«*«HKt******l 


r***************************** 

*  F»ROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

*  DATE:  17  August  1988 

*  VERSION:  1.0 

*  TITLE:  &(dude  one  object  from  a  list  of  onsets 

*  RLENAME:  exclude.8 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

*  AUTHOR:  CaptG.R.GIer 

*  CONTENTS 

*  CLASSES:  none 

*  METHODS:  none 

*  COMMANDS:  none 

*  TOOLS:  none 

*  UTILITIES:  exciude.s 

*  SYS/MACRO:  none 

*  CALLED  BY:  relay-lt 

*  CALLS:  none 

*  INPUTS:  Object-key,  List  of  Ot^ects 

*  OUTPUTS:  List  of  Objects  wither  object-key. 

*  VARIABLES  USED:  none 

*  VARIABLES  CHANGED:  none 

*  RLES  READ;  none 

*  RLES  WRITTEN:  none 


*  FUNCTION: 

*  This  module  excludes  an  object  from  a  list  of  objects,  returning  a  list 

*  of  the  remaining  objects.  This  module  is  called  when  (relay  Node ...) 

*  wants  to  pass  a  message  to  every  link  except  the  link  that  brought  the 

*  message. 

.**««****««*«*#**************************««***********«***«****1t***4t*«*«**** 


(define  (exclude  Object  Lst) 

(corxi  ((nutf?  Lst)  nl)  *  * 

((e^  Object  (car  Lst))  (exclude  Object  (edr  Lst))) 
(else  (cons  (car  Lst)  (exclude  Object  (edr  Lst)))))) 


I 

I 

I 


95 


) 

I 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENfTH  248 

DATE:  17  August  1988 
VERSION;  1.0  .  . 

TITLE:  Paren  remover 
RLENAME:1lattaa8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTILITIES:  flatten 
SYS/MACflO;  none 

CALLED  BY;  Channels,  Circuits.  Nodes 
CALLS:  none 

INPUTS:  List 

OUTPUTS;  List  without  muiipie  wrappings  of  parentheses 

VARIABLES  USED:  none 
VARIABLES  CHANGED:  none  ‘  * 

RLES  READ;  none 
RLES  WRITTEN:  none 


FUNCTION; 

This  utllty  removes  multiple  levels  of  parentheses,  returning  a  proper 
list  of  the  original  objects.  It  is  used  to  standardize  the  input  for 
other  nKxJules. 


(define  (flatten  Lst) 

(if  (atom?  Lst) 

OistLst) 

(apply  append  (mapcar  flatten  Lst)))) 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  18  August  1988 
VERSION:  1.0 

TITLE:  Gateway  out  of  Scheme  to  DOS 
RLENAME:  ouLS 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.Gi6r 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UnUTIES:  out 
SYS/MACRO:  none 

CALLED  BY:  User 
CALLS;  none 

INPUTS:  none 
OUTPUTS:  none 

VARIABLES  USED:  none 
VARIABLES  CHANGED;  none 
FILES  READ;  none 
RLES  WRITTEN:  none 


FUNCTION: 

The  utility  Out  temporarly  suspends'PC  Scheme  and  gives  you  the  DOS 

prompt  Out  harxlly  faclitates  creation  of  load  files 

as  the  executable  nrake_M  program  does  not  work  within  PC  Scheme. 


(define  (out)  0 
(dos-call’"“4095)) 


r 
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:*  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

;*  DATE:  17  August  1988 
VERSION:  1.0 

;*  TrrLE:I)etarmining  the  number  of  channsis  that  could  be  preempted 

;*  RLENAME:  preempts 
.* 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

•*  CONTENTS 

CLASSES:  none 
;*  METHODS:  none 
COMMANDS:  none 
;*  TOOLS:  none 

unUTIES:  preempt + ,  accum + 

SYS/MACflO:  none 

;*  CALLED  BY:  sort 
;*  CALLS:  accum  + 

:*  INPUTS:  Vector 

;*  OUTPUTS:  A  modified  vector  that  shows  the  number  of  available  channels 

;*  for  each  priority. 

.« 

;*  VARIABLES  USED:  none 
;*  VARIABLES  CHANGED:  none 
;*  RUES  READ:  none 
:*  FILES  WRITTEN:  none 


:*  FUNCTION: 

;*  This  utlity  takes  a  vector  and  cascade-sums  from  the  lowest  priority 
;*  to  the  highest  priority.  Forexample,  preempts  would  operate  on  a 
;*  link  cost  vector  of  #(1  2  03)  and  return  as  output  #(653  3). 

;*  The  lowest  priority  or  spare  value  is  3.  Preempt -»■  retains  3  in  the  for 
;*  right  column  arxl  adds  it  to  0  In  the  'c  priority  column  yielding  3  also. 
;*  NexL  2  from  the 'b  priority  column  is  added  to  the  previous  sum  3, 

;*  givings.  Finally  the  single 'a  priority  brihgs  the  far  left  column 
;*  totaltoS.  The  resultant  vector  signifies  that  an 'a  priority  circuit 
;*  could  use  five 'b 'cor  spare  resources  but  no 'a  priority  resources. 


(define  (preempt  +  Vector)  ;Format:  #(A-prlor  B-prior  C-prior  Spare). 
Oist-  >  vector  ;Convert  to  a  list  for  recursion, 

(accum  +  ;Cail  list  version. 

(vector- >  list  Vector))))  .Convert  back  to  a  vector. 
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(define  (accum  -t-  Let) 

(H  (nuH?  Let)  nl;lf  zero  or  'Q.  nl. 

(cons  (apply  +  Let)  (accum  +  (cdr  Let)))))  ;Add  aH  to  the  right. 


END  * 

* 

**«****««*A*A*A**«*****AAA*AA****««****««*************************** 
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A**************************************************************************** 

PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  21  August  1988 
VERSION:  1.0 

TITLE:  Selecting  a  channel  allocated  to  a  circuit  from  a  channel  list 
RLENAME:  8el_chan.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.Gier  .  . 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTILITIES:  select-channel 
SYS/MACRO:  none 

CALLED  BY;  relay-it 
CALLS:  select-channel 

INPUTS:  Circuit-ID,  Channel  list 

OUTPUTS:  Machine  code  representation  of  channel 

VARIABLES  USED;  Circuit 
VARIABLES  CHANGED;  none 
RLES  READ:  none 
RLES  WRITTEN;  none 


*  FUNCTION: 

*  •  * 

*  The  utility  Select-Channel  finds  the  channel  that  owns  Circuit-ID  from  a 

*  list  of  channels  and  returns  the  object  Channel  if  successful,  or  false 

»  if  not 

* 


(define  (select-channel  Circuit-ID  Channels) 

(if  (null?  Channels) 

#F 

(ff  (eq?  (eval  Circuit-ID)  (send  (car  Channels)  get-Circuit)) 
(car  Channels) 

(select-channel  Circuit-ID  (odr  Channels))))) 


•  It 


* 


END 


* 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  17  August  1988 
:*  VERSION:  1.0 

;*  TITLE:  Tack  the  name  of  a  node  or  link  to  the  beginning  of  a  path 

;*  RLENAME:  tack_on.8 
.* 

:*  OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edttion)  w/SCOOPS 
AUTHOR:  Capt  G.R.  Gler 

.* 

:*  CONTENTS 

CLASSES:  none 
;*  METHODS:  none 
COMMANDS:  none 
;*  TOOLS:  none 
:*  UnUTIES:  tack-on  .  . 

:*  SYS/MACRO:  none 

.* 

;*  CALLED  BY:  relay-lt 
CALLS:  none 

INPUTS:  Node  or  Link,  and  Message 

;•  OUTPUTS:  Updated  path 

.* 

VARIABLES  USED:  Name 
;*  VARIABLES  CHANGED:  none 
;*  FILES  READ:  none 
:*  FILES  WRITTEN:  none 

;•  FUNCTION: 

;*  The  Tack-On  utUity  Inserts  the  symbolic  representation  of  a  link  or  node 

;*  at  he  beginning  of  the  existing  Path  list. 

.* 

.**************«•***«**********«*•««««*«************************************ 

(define  (tack-on  Object  Message) 

(let*  ((Path  (list-ref  Message  5)) 

(fteme  (if  (symbol?  Object)  Object  (send  Object  get-Name)))  ;Get  name. 
(New-Path  (append  (list  Name)  Path))) 

(list  (list-ref  Message  0) 

(list-ref  Message  1) 

Oist-ref  Message  2) 

Oist-ref  Message  3) 

(list-ref  Message  4) 

New-Path)))  ;Glve  back  message  with  modified  path. 


END 


************ 


******************************************** ******************«*********4 

*  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

*  .  . 

*  DATE:  18  August  1988 

*  VERSION:  1.0 

*  TITLE:  Remove  duplicate  elements  from  a  list 

*  FILENAME:  undup.s 

* 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  EdUon)  w/SCOOPS 

*  AUTHOR:  CaptG.R.Gier 

* 

*  CONTENTS 

*  CLASSES:  none 

*  METHODS:  none 

*  COMMANDS:  none 

*  TOOLS:  none 

*  UTILITIES:  undup 

*  SYS/MACRO:  none 

* 

*  CALLED  BY:  owns-channels,  owns-circuits,  owns-links,  owns-nodes,  table-lookup 

*  CALLS:  undup 

* 

*  INPUTS:  Ust 

*  OUTPUTS:  List  with  no  duplicate  elements 

* 

*  VARIABLES  USED:  none 

*  VARIABLES  CHANGED:  none 

*  RLES  READ:  none 

*  RLES  WRITTEN:  none 

* 

* 

•  FUNCTION: 

* 

*  The  utnity  Undup  removes  duplicate  elements  from  a  list,  and  removes 

*  the  '0  left  by  deni  objects  and  the  'Spare  returned  by  channels. 

*  presenting  a  list  of  living  objects  only. 

* 


(define  (undup  Lst) 

(cond  ((null?  Lst)  nl)  lEmpty  iisL  stop. 

((null?  (car  Lst))  (undup  (cdr  Lst)))  ;Skip  over  '0- 
((symb^  (car  Lst))  (undup  (cdr  Lst)))  ;Flter  out  'Spare, 
((member  (car  Lst)  (cdr  Lst))  (undup  (cdr  Lst)));Skip  dui^icate. 
(else  (cons  (car  Lst)  (undup  (cdr  Lst))))))  ;Buld  undup  list. 

.******************«**«********«*****t>********************< 

I 

•  *  * 

:*  END  * 
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*«***««««********************************************************************* 

*  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

*  DATE:  18  August  1988 

*  VERSION:  1.0 

*  TITLE:  Detennine  If  one  vector  Is  greater  than  another 

*  RLENAME:  vec_gLs 

*  OPER  SYS:  DOS  VERSION  3.2 

*  LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 

*  AUTHOR:  CaptG.R.Gier 

*  CONTENTS 

*  CLASSES:  none 

*  METHODS:  none 

*  COMMANDS:  none 

*  TOOLS:  none 

*  UTILITIES:  v> 

*  SYS/MACRO:  none 

*  CALLED  BY:  relay-lt,  sort 

*  CALLS:  none 

*  INPUTS:  nulls  or  vectors 

*  OUTPUTS:  boolean 

*  VARIABLES  USED:  none 

*  VARIABLES  CHANGED:  none 

*  FILES  READ:  none 

*  FILES  WRITTEN:  none 


*  FUNCTION: 

* 

*  V>  compares  the  first  vector  to  the  secorxl  and  returns  true  if  greater 

*  than  the  second  and  false  if  less  than  or  equal  to  the  second.  If 

*  handed  the  cost  of  a  dead  channel,  'Q.  V>  converts  the  ni  into  the 

*  nun  vector  and  proceeds  with  the  comparison.  If  wrapped  in  a  list, 

*  V>  strips  the  li^  Examples: 

*  (v>  #(1  0  0  0)  #(0 1  0  0))  ->  true. 

*  (v>  #(5  5  5  5)  #(5  5  5  4))  ->  true. 

*  (v>  #(0987)  #(1  0  0  0))  ->  false. 

*  (v>  #(0 0 0 0)  #(0 0 0 0))  ->  false. 


(define  (v>  Object-1  Object-2) 

(let  ((V-1  (cond  ((vector?  Object-1)  Object-1) 
((nun?  Object-1)  (vector  00  0  0)) 
(else  (car  Object-1)))) 

(V-2  (cond  ((vector?  Object-2)  Object-2) 
((nuH?  Object-2)  (vector  0000)) 
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(else  (car  Oblect.2))))) 

(do  ((IndexO  (1  +  Index))  ;Flr8t  iteration  has  no  meaning. 

(First) 

(Second) 

(GT  #F  (>  First  Second))  ;Set  GT  flag  to  false,  wait  for  change. 

(LT  #F  (<  First  Second)))  ;SetLT  flag  to  false,  wait  for  change, 

((or  GT  LT  (>  Index  3))  GT)  iCheck  flags,  donT  exceed  vector 
length. 

(set!  First  (vector-ref  V-1  index))  ;Chedc  from  left  to  right 
(set!  Secotxl  (vector-ref  V-2  index))))) 


END 


* 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  18  August  1988 
VERSION:  1.0 

TITLE:  Sum  a  list  of  VQCtors  by  element 
RLENAM&vec_plu8.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  Capt  G.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTILITIES:  v+ 

SYS/MACRO:  none 

CALLED  BY:  cost-vector,  relay-lt 
CALLS:  none 

INPUTS:  List  of  vectors  .  . 

OUTPUTS:  Vector 

VARIABLES  USED:  none 
VARIABLES  CHANGED:  none 
RLES  READ:  none 
RLES  WRITTEN:  none 


FUNCTION: 

The  utlityV-t- sums  a  list  of  vectors  from  light  to  left.  Notethatno 
vector  units  carry  In  the  process. 


(define  (v-i-  V-Ust) 

(do  ((N  3  (-1  +  N))  ;A  four  place  vector. 

(V-Sum  '0  ;A  list  accumulator. 

(cons  (apply  +  (mapcar 

(lambda  Rector)  (vector-ref  Vector  N)) 

V-Ust)) 

V-Sum))) 

((negative?  N)  OM-  >  vector  V-Sum)J)) .  ;Convert  from  list  to  vector. 


END 
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r***********************«*****«**«*******«******i 


PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  2  September  1988 
VERSION:  1.0 

UTLE:  Qiaphlcs  module  for  nodes  and  links 
RLENAME:  diaw-S 

OPER  SYS:  DOS  VERSION  3.2  ■  * 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.Gier 

CONTENTS 
CLASSES:  none 
ME1T100S:  coord,  draw 
COMMANDS:  none 
TOOLS:  norm 

UnUTIES:  dear,  dipper,  list  +  ,  normal,  x-ref-text,  x-ref-graph, 
y-ref-texL  y-rd-graph 
SYS/MACRO:  none 

CALLED  BY:  reiay-it 

CALLS:  dipper,  list+,  living,  normal,  x-ref-tttd,  x-ref-graph, 
y-fef-text,  y-ref-graph 

INPUTS:  Color,  From-node,  To-node,  Link-Cost 
OUTPUTS:  Graphics 

VARIABLES  USED:  Name 
VARIABLES  CHANGED:  none 

FILES  READ:  none  .  . 

RLES  WRITTEN:  none 


FUNCTION: 

Draw  contains  routines  that  permit  the  user  to  visually  observe  the  search 
and  allocation  processes.  The  first  node  is  always  draw  at  the  top  of  the 
screen,  or  12  o'clock  position.  AddWond  nodes  are  drawn  dockwise, 
anguiarty  spaced  equi-distant  from  each  other.  The  nodes  are  drawn  using 
text  coordinates,  but  the  links  are  drawn  using  graphics  coordinates. 
Clipper  prevents  a  line  from  drawing  over  a  node  already  on  the  screen. 
The  Clear  and  Normal  utllties  help  reset  the  screen  for  graphics  and  text 
modes  respectively. 


(define-method  (NODE  coord)  Q 

(let*  ((Angle-irvRadians  (-  (/  pi  2) 

(( (*  2  pi  (subi  Seriai-Number)) 
Popdation))) 

(X  (round  (*  280  (cos  Anglefo-Radians)))) 
(Y  (round  (*  160  (sin  Anglefo-Radians))))) 
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(consXY))) 

(deflne-method  (NODE  diaw)  {Cdoi) 

Oat*  {i^Me-Coonl  (cooid)) 

(Une  (y^-t8Kt  (odr  Noda-Cooid))) 

(Coi  (-  (x-raf-taod  (car  Node-Coord))  4)))  ;Lj8ft.  to  canter  text 
(vwindow-aat-poaltioni  Raciangla  Una  CoO 
(windCMV-aat-aizel  Ractangto  1  8) 

(cond  (OMng)  ;Whiai8l5.U]t-Ml8  6l.Maganlal8  5.Grayl8  56. 
(wbidowv-sat-attributal  Ractanj;^  'BordBr-Attributea  Color) 
(window-set-attrtxael  Ractangla  Taod-Attiibutas  15)) 

(alaa 

(window-aat-attrttMJtel  Ractangla  'Bordar-Attrtbutas  56) 
(windovw-aat-attributal  Rectangle  Text-Attrtbutaa  56))) 
(window-dear  Ractangla) 

(display  Name  Rectangle)))  ■  * 

(define  (x-ref-text  X) 

(truncate  (( (4-  X 320)  8))) 

(define  (y-raf-text  Y) 

(truncate  (/  (- 174  Y)  14))) 

(define-mathod  OJNK  draw)  (Color  From  To  Link-Cost) 

Oet*  ((Nodal  (send  (car  Nodes)  coord))  .Stored  representation 
(Node2  (send  (cadr  Nodes)  coord))  ;prever^  duai  iabels 
(Pretty-<^  (V  Unk-Cost  (\^or-  >  iist  Unk-Cost))) 

(Cllpl  (dipper  From  To)) 

(Clip2  (dipper  To  From)) 

(Qlppings  Cist  4-  Oist  Qipl  aip2))) 

(Orie-Third-X  (round  (x-raf-text 

^  (4-  (*  (car  Nodal)  2)  (car  Node2))  3)))) 
(One-TNrd-Y  (round  (y-raf-text 

^ (4-  (•  (odr  Nodal)  2)  (cdr  Node2))  3))))) 
(set-dIpping-recUNigle!  (car  Clippings) 

(cadr  cappings) 

(caddrCNppings) 

(cadddr  cuppings))  .  . 

(position-pen  (car  From)  (odr  From)) 

(cond  ((living)  (sat-perKOdorl  Color))  ;IJght-GFsen  or  Green. 

(else  (set-pen-odorl  ’Gray))) 

(draw-lin»4o  (car  To)  (odr  To)) 

(set-dipping-fectanglel  -320 174  319  -175) 

(cond  (LInk-Coet 

(window-set-DOsItloni 

Score-Board  (subi  One-Third-Y)  (-  One-Third-X  5)) 
(window-set-sizet  Score-Board  2 10) 

(window-dear  Score-Board) 

(display Score-Board) 

(display  Name  Score-Board) 

(display  #\new4ine  Score-Board) 

(display  Pr^-Cost  Score-Board)) 
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(eteenl)))) 


(define  (K-fef-graph  X) 

(-  (*  (truncate  (( (-t^  X  320)  8))  8)  320)) 

(define  (y^-graph  Y) 

(-  i*  (truncate  ^  (+  Y 175)  14))  14)  175)) 

(define  (dipper  Cooidl  Cooid2)  ;  Q  F  E 

Oet*((x-arcar)  ZDODOOOOODODDDODDD? 

(y-ofcdr)  3  3 

(X(xHref-graph()(-orCoord1)))  :  H3  XY  D3 
(Y(y^-graph(y-d  Cooidl)))  3  3 

(A  (cons  (-  X  39)  (•  Y  9)))  ® DDOODODODDODDDDDDY 

(C(cone(+X38)(-Y9)))  ;  A  B  C 

(E(con8(-t-X38)(+ Y21))) 

(G(cons(-X39)(+ Y21))) 

(Angle-A  (atan  (-  (y-of  A)  (y-of  Coordi))  (-  (x-of  A)  (x-of  Coordi)))) 
(Angled  pi -2)) 

(Angle-C  (atan  (- (y-of  Q  (y-of  Coordi))  (-(x-ofC)  (x-of  Coordi)))) 
(Anflfe-00) 

(Angle-E  (atan  (-  (y-of  E)  (y-of  Coordi))  (-  (x-of  E)  (x-of  Coordi)))) 

(Angle-F(/pl2))  •  - 

(Angle-G  (atan  (-  (y-of  G)  (y-of  Coordi))  (-  (x-of  G)  (x-of  Coordi)))) 

(Angle41pi) 

(Theta  (atan  (-  (y-of  Coord2)  (y-of  Coordi)) 

(-  (x-of  Coord2)  (x-of  Coordi))))) 

(cond  ((<  Theta  Angle-A)  ‘(0  .(y-of  G)  .(x-of  G)  0  )) 

((<  Theta  Angle-B)‘(0  .(y-of  C)  .(x-of  QO  )) 

((<  Theta  Angle-C)  ‘(.(x-of  A)  .(y-of  A)  0  0  )) 

((<  Theta  Angle-D)  '((x-of  E)  .(y-of  E)  0  0  )) 

((<  Theta  Angled)  ‘(.(x-of  C)  0  0  .(y-of  C))) 

((<  Theta  Angle-F)  ‘(.(x-of  G)  0  0  .(y-of  G))) 

((<  Theta  Angle-G)  ‘(0  0  .(x-of  E)  .(y-of  E))) 

(else  ‘(0  0  .(x-of  A)  .(y-of  A)))))) 

(define  (liet-f  Clippings) 

(do  ((N  3  (-1  -t-  N));A  four  place  list 
(Sian  ’0'.A  list  accumulator. 

(cons  (apply  h-  (mapcar 

(lambda  (Lst)  (list-ref  Lst  N)) 
aipplngs)) 

Sum))) 

((negative?  N)  Sum)))  ;Retum  totalled  list 

•  • 

(define  (dear) 

(set-vUeo-model  16) 

(windoMi-sat-positioni  'console  0  0) 

(windcMi-set-sizel  'console  25  80) 

(window-dear 'console) 

(window-set-poeMonl  'console  23  0) 

(window-set-sizei  'console  2  35) 
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(windcw-sat-poskioni  pcs-status-^window  24  SO) 
(windcw-set-stzel  pc»4tatU8-wlnclo«v  1  30)) 

(daflns  (nonnaQ 
(set-videtHnodel  3) 

(windONv-aat-poaUonI  'conaoia  0  0) 
(windo^-aat-sbel  'console  24  80) 

(window-deer  ’console)) 
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t**********«**«1 


PROTOTYPE  ROUTE  PLANNER  FOR  2ENrrH  248 

DATE:  18  August  1988 
VERSION:  1.0 

TITLE:  Identify  those  lies  to  be  loaded  during  mn  time 
RLENAME:  autoload.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  Capt  G.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTIUTIES:  none 
SYSA4ACRO:  autoload 

CALLED  BY:  Scheme 
CALLS:  Any  file  listed 

INPUTS:  Not  user  accessible 
OUTPUTS:  Invisible  to  user 

VARIABLES  USED:  none 
VARIABLES  CHANGED:  none 

RUES  READ:  Any  fast-load  fie  listed  in  this  program 
RLES  WRITTEN:  none 


FUNCTION: 

Scheme  uses  this  fie  to  interactively  load  blocks  of  code  on  demand. 
Each  line  Uentifles  the  fasdoad  ne  to  load  from  C  ■fsi")and 
a  list  of  the  narnes  of  functions  within  the  block.  Some  of  the  blocks 
include  method  definitions  that  the  function  cals,  but  none  of  the  blocks 
contain  only  methods  as  there  is  no  means  to  call  them.  The  auto  load 
fie  saves  computer  memory  as  many  of  the  tools  below  do  not  need  to 
be  loaded  unless  one  wants  to  inspect  specific  objects. 


(autoload-from-fle  "undup.fsT  ’(tmdup)) 
(autoioad-frotn-fle  "flatteafsl”  '(Ratten)) 
(autdoad-from-fle  1ook.fsl"  '(look)) 
(aiAoload-fronvfle  1lfe.fsr  '(dead  alive  living?)) 
(autoload4rom-lle ‘Vec.gLfsT  '(v>)) 
(autoload-from-ne  'VscIpius.fSI*  '(v-t-)) 
(autoload-from-fle ’TireemptfsT  '(preempt +)) 
(autoload-from-fle  "exdude.fsr  '(exclude)) 


p 


(autoioad4roin-ll«'lack_oaf8i*  ’(tack-on)) 
(autoload-fronvito  "cosLftf*  ’(cost?)) 
(autdoacMrom-fle  "nodas.M”  ’(nodes?)) 
(autokiad-froin-fle'links.ltf'  ’Oinks?)) 
(autdoad-lronfKfle  "channeis.ltf’  ’(channels?)) 
(autoiosKMram-ile  "drcufts.M*  ’(circuits?)) 
(autoload-lronfvfle  "raquests-M*  ’(requests?)) 
(autokMd-frorTKlIe'lreplies.ltf'  ’(replies?)) 
(autoload-fronHIe  lnc.M*  ’(me)) 

(autoload-from-fle  ’’pr.M*  '(pi)) 

(autdoad-from-lle  "ouLfaf  ’(out)) 

(autdoad-fronvfle  ‘telay-fsT*  ’(relay)) 

(autoioad-from-ffe  "sel_chan.fel”  ’(select-channai)) 


# 

END 

* 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  6  September  1988 
VERSION:  1.0 

TITLE:  Macro  for  compling  al  PRP  flee  In  their  proper  order 
RLENAME:  comple.me 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  Capt0.aGier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UnUTIES:  none 

SYS/MACRO:  complation  macro 

CALLED  BY:  User 
CALLS:  none 

INPUTS:  none 
OUTPUTS:  none 

VARIABLES  USED:  none 
VARIABLES  CHANGED:  none 

RLES  READ:  Source  lies  with  .srextentlon 
RLES  WRITTEN:  Object  ties  with  .so  extention 


FUNCTION: 

Works  the  same  as  If  the  programmer  were  to  type  in  all  the  PRP  files  for 
individual  complatioa  Outputs  OK  when  each  fie  complation  is  complete. 


Goad  "c:scoop8.fsr) 

(comple-Ale  *a:ciass.s”  ''a:class.so") 
(display  "class  OK  ") 

(compie-fle  ”a:draw.8"  "a:draw.so") 
(display  "draw  OK  ") 

(comple4le  "a.1latten.8"  "a:flatten.so") 
(display  "flatten  OK  ") 
(compie4le"a:undup.s"  "a:undup.so") 
(display  "undup  OK  ") 

(compie-fle  "a:iook.s"  *a:look.so") 
(display  "fook  OK  ") 

(compia4le  "a:life.tf'  "a:life.so") 
(diaplaylifoOK  ") 

(compie-fle  "anrec_gLr  "a:vec_gLso") 
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(display  ■Vector  >  OK  *0 
(compto-fle  '■a.'vscjiius.S'  "aivacjalus.sd') 
(display 'Vector  plus  OK  *) 
(compla-fle''a:prsempLs"  ''a:pr8einpL8o'') 
(display 'txaempt  OK  ") 

(complo  lie  "a:e)cdude.8*  "aiexciuda.so") 
(display  "exclude  OK  ") 

(compie4le  "a-tack  oae*  "a.iack  on.atf) 
(display  "tack  on  OK  ") 

(comple-fle  "a.iablo_lu.e'  "a-lablejaso") 
(display  "table  lookup  OK  ") 
(coniple4le"a:cosL8"  "a:cosLso") 
(display  "cost  OK  ") 

(complex  "a:ouL8"  "acouLstf') 

(display  "out  OK  ") 

(comple-fle  "a:8el_chaas"  "a:sel_chan.so") 
(display  "select  channel  OK  ") 
(comple-fle  "arsons"  "arsonso") 

(display  "sort  OK  ") 

(comple-fle  "arrelay.s"  "arraiay.so") 
(display  "relay  OK  ') 

(complete  "a:nodes.s"  "a:nodes.so") 
(display  "nodes  OK  ") 

(comple-fle  "a:iinks.s"  "a:links.so") 
(display  links  OK  ") 

(comple-fle  "a:channels.s"  "a:channels.80") 
(display  "channel  OK  ") 

(comple-fle  "a:circuits.8"  "a:circuit8.so") 
(display  "drcutts  OK  ") 

(complefle  "a;requests.s"  "arrequests-so") 
(display  "requests  OK  ") 

(complefle  "a:replies.S"  "a:replies.so") 
(display  "replies  OK  ") 

(comple-fle  "arm&S"  "a:mc.so") 

(display  "make  circuit  OK  ") 

(complefle  "a:pr.r  "arpr.so") 

(display  "print  circuit  OK  ") 

(complefle  "a:diamond.s"  "a:diamond.so") 
(display -diamond  OK  ") 

(complefle  "a:stlck.s"  *a:stick.so*) 
(display  "stick  OK  ") 

(complefle  "a:star.s"  "arstar.so") 

(display  "star  OK  ") 

(complefle  "a:autoload.s"  "a:autoload.so") 
(display  "autoload  OK") 


END 

* 
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ECHO  OFF 

M************************************************************ 

REM  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

REM 

REM  DATE:  1  September  1988 
REM  VERSION:  1.0 

REM  TITLE:  DOS  belch  file  for  making  PRP  test-load  files  from  object  files 

REM  RLENAME:  te8tfoad.bat 

REM 

REM  OPER  SYS:  DOS  VERSION  3.2 
REM  LANGUAGE:  DOS 
REM  AUTHOR:  Capt  G.R.  Gler 
REM 

REM  CONTENTS 

REM  CLASSES:  none 

REM  METHODS:  none 

REM  COMMANDS:  none 

REM  TOOLS:  none 

REM  unUTIES:  none 

REM  SYS/MACRO:  testload  batch  file 

REM 

REM  CALLED  BY;  User 
REM  CALLS:  none 
REM 

REM  INPUTS;  none 
REM  OUTPUTS:  none 
REM 

REM  VARIABLES  USED:  none 

REM  VARIABLES  CHANGED;  none 

REM  FILES  READ:  make_fsl.exe 

REM  RLES  WRITTEN:  testload  files  with  an  .fsl  extention 

REM 

REM 

REM  FUNCTION: 

REM  This  botch  file  makes  multiple  calls  to  make_fst.exe  so  as  to  convert 
REM  object  files  to  tesUoad  files  using  the  Scheme  utBity  make-fastioad. 
REM************************************************************** 
ECHO  ON 

make.tel  a:cteS8.so  a;ciass.tel 
make.tel  a:draw.so  a:draw.fsl 
make_tel  a.’ftetteaso  a.ilatten.fsl 
make.fsl  a:undup.so  a:undup.fsl 
make_tel  a:look.so  a:fook.fsl  ‘  * 
make_tel  a:llfe.ao  a:iite.tel 
make.tel  a:vec_gLso  a:vec_gLf8l 
maka_tel  a.'vec _plua.so  a.'vecjiius.tel 
make.tel  a:praampLao  a:preemptfsl 
make_tel  a:eKciude.so  a:eKclude.f8i 
maka_tel  adack_oa80  a:tack_on.fsl 
make.fal  a:tabieju.80  a.table Jafsl 
make'tel  a:co^so  a:co^tei 
make_tal  a:ouL80  a:ouLtet 
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make.fsl  a:sel_chan.8o  a:sel_chaafsl 
make_fel  arsortso  a:8ortfi8i 
make_fsl  a:relay.so  a:relay.fsi 
makejsi  ainocWso  a:nodes.f8l 
make_fsl  a:links.so  a:link8.fsl 
make_fei  a:channels.80  a;channels.fsl 
make_f8l  a:circuit8.80  a:circuits.fsl 
make^fsl  a-requeats-so  a:reque8t8.f!)l 
make_fsl  a:replies.so  a:repiies.fd 
make_fel  a:m&80  a:mc.M 
make_fsl  a:pr.so  arpr.fsl 
make_fsl  a:dlafnond.so  a:diamond.fsl 
make_f8l  a:stick.so  a:stfck.(sl 
make_f8l  a:star.so  a:star.fsi 
make^fsl  a:autoload.so  a:autoload.fsl 

REM  **************-*******•******* 
REM 

REM  END 

REM 

REM  ****************************** 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  25  October  1988 
VERSION:  1.0 

TITLE:  Scheme  Initialization  flea 
RLENAME:  acheme.inl 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.  Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTIUTIES:  none 

SYS/MACRO:  scheme  initialization 

CALLED  BY;  User 
CALLS:  none 

INPUTS:  none 
OUTPUTS:  none 

VARIABLES  USED:  none 
VARIABLES  CHANGED;  none 

RLES  READ:  Those  .fsl  files  listed 
RLES  WRITTEN:  none 


:*  FUNCTION; 

.« 

1 

Calls  fasUoad  fles  in  the  proper  ordw  td  execute  PRP  when  PC  Scheme  is 
;*  first  called. 

t 

(load  "c;scoops.fsn 
(load  "dass.fsT) 

(load  "autotoad.fsP) 

Ooad  "draw.fsT) 

(load  lableJafsH 

Ooad  "sort.fer) 

(dear) 

* 

*  END 

• 

* 

* 

• 

116 


ECHO  OFF 

REM*********************************************************-  Ir****************** 

REM  PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

REM 

REM  DATE:  9  August  1988 
REM  VERSION:  1.0 

REM  TITLE:  Batch  fie  for  loading  Scheme 

REM  RLENAME:  prp.bat 

REM 

REM  OPER  SYS:  DOS  VERSION  3.2 
REM  LANGUAGE:  DOS 
REM  AUTHOR:  CaptG.R.Gier 
REM 

REM  CONTENTS 

REM  CLASSES:  none 

REM  METHODS:  none 

REM  COMMANDS:  none 

REM  TOOLS:  none 

REM  UnUTIES:  none 

REM  SYS/MACRO:  PRP  preparatory  batch  fQe 

REM 

REM  CALLED  BY:  User 
REM  CALLS:  none 
REM 

REM  INPUTS;  none 
REM  OUTPUTS:  none 
REM 

REM  VARIABLES  USED:  none 
REM  VARIABLES  CHANGED:  none 
REM  RLES  READ;  pcs.sxe 
REM  FILES  WRITTEN:  none 
REM 
REM 

REM  FUNCTION: 

REM 

REM  This  batch  Ne  changes  path  information  so  that  Scheme  can  be  read  from 
REM  the  C:  drive  and  PRP  can  be  read  from  the  A:  drive.  Lastly  it  calls  PC 
REM  Scheme. 

REM  *****************************************************.M******************** 

ECHO  ON  •  * 

cd  c:\scheme 

path -c:\scheme;  a:\ 

cda: 

pcs 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  2S  August  1988  .  . 

VERSION:  1.0 

Trn^:  Dtamond  shaped  netwvorkfla 
RLENAME:  diamond.s 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.GIer 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UnUTIES:  none 
SYS/MACRO:  none 
NETWORK:  diamond 

CALLED  BY:  User 
CALLS:  none 

INPUTS:  none 
OUTPUTS:  Network  objects 

VARIABLES  USED:  *Circuit-IO*,  Popviatk)n 
VARIABLES  CHANGED;  Population 
RLES  READ:  none 
RLES  WRITTEN:  none 


FUNCTION: 

This  block  of  code  contains  the  commands  to  create  a  network  of  four 
nodes,  five  links,  17  channels  and  two  circuits.  It  looks  like: 

CNCE-1 

Define  nodes  before  L-4 /|\  L-1  been  created.  Use  the 

links,  links  before  /  |  \  message  send  format  to 

channels,  and  channels  CNCE-4  L-5 1  CNCE-2  beck  connect  prevtous 
before  circuits.  You  \  |  /  oi^ects. 

can  set  instance  variables  L-3  \|/  L-2 
to  objects  that  have  already  CNCE-3 


(setcv  NODE  Population  0)  ;Reset  the  node  population  upon  loading, 
(define  *Clrcuit-ID*  2)  ;protect  the  two  pre^reeted  circuits. 

(define  CNCE-1 
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(make-instance  NODE 

’Name’CNCE-l)) 

(define  CNCE-2 
(make-instance  NODE 

’Name 'CNCE-2)) 

(define  CNCE-3 
(make-htMance  NODE 

'Name ’CNCE-3)) 

(define  CNCE-4 
(make-instance  NODE 

'Name 'CNCE-4)) 

(define  UNK-1 
(make-instance  LINK 
'Name’UNK-1 

'Nodes  (list  CNCE-1  CNCE-2))) 
(define  UNK-2 
(make-instance  LINK 
'Name ’UNK-2 

'Nodes  (list  CNCE-2  CNCE-3))) 
(define  UNK-3 
(make-instance  UNK 
'Name  'UNK-3 

'Nodes  (list  CNCE-3  CNCE-4))) 
(define  UNK-4 
(make-instance  UNK 
'Name  ’UNK-4 

'Nodes  (list  CNCE-4  CNCE-1))) 
(define  UNK-S 
(make-instance  UNK 
'Name  'UNK-5 

'Nodes  (list  CNCE-3  CNCE-1))) 
(define  CHANNEL-11 
(make-instance  CHANNEL 

'Name ’CHANNEL-11 
'Unk  UNK-1)) 

(define  CHANNEL-12 
(make-instance  CHANNEL 

'Name 'CHANNEL-12 
Unk  UNK-1)) 

(define  CHANNEL-13 
(make-instance  CHANNEL 

'Name  'CHANNEL-13 
Unk  UNK-1)) 

(define  CHANNEL-14 
(make-instance  CHANNEL 

'Name 'CHANNEL-14 
'Unk  UNK-1)) 

(define  CHANNEL-21 
(make-instance  CHANNEL 

'Name ’CHANNEL-21 
'Link  UNK-2)) 

(define  CHANNEL-22 


(make-initancs  CHANNEL 

’Name ’CHANNEL-22 
’Unk  UNK-2)) 

(define  CHANNEL-23 
(make-instance  CHANNEL 

’Name ’CHANNEL-23 
’Link  UNK-2)) 

(define  CHANNEL-24 
(make-instance  CHANNEL 

’Name ’CHANNEL-24 
’Unk  UNK-2)) 

(define  CHANNEL-dl 
(make-instance  CHANNEL 

’Name ’CHANNEL-31 
’UnkUNK-3)) 

(define  CHANNEL-32 
(make-kistance  CHANNEL 

’Name  ’CHANNEL-32 
'LinkUNK-3)) 

(define  CHANNEL-33 
(make-instance  CHANNEL 

’Name ’CHANNEL-33 
'Link  UNK-3)) 

(define  CHANNEL-34 
(make-instance  CHANNEL 

’Name  ’CHANNEL-34 
’Link  UNK-3)) 

(define  CHANNEL-41 
(make-instance  CHANNEL 

’Name  ’CHANNEL-41 
'Link  UNK-4)) 

(define  CHANNEL-42 
(make-instance  CHANNEL 

’Name  ’CHANNEL-42 
’Link  UNK-4)) 

(define  CHANNEL-43 
(make-instanca  CHANNEL 

’Name ’CHANNEL-43 
’Link  UNK-4)) 

(define  CHANNEL-44 
(make-instance  CHANNEL 

’Name ’CHANNEL-44 
'Link  UNK-4)) 

(define  CHANNEL-51 
(make-kistance  CHANNEL 

’Name ’CHANNEL-51 
’LinkUNK-5)) 

(define  aRCUfT-1 
(make-instance  CIRCUtT 
’fteme  ’QRCUrr-1 
’Priority-Cost  (vector  0  0 1  0))) 
(define  aRCUIT-2 
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(make-insianoe  CtRCUIT 
’Name*aRCUIT-2 
‘Priority^kMt  (vector  0 1  0  0)))  • 

(send  CNCE-1  set-Unks  (Hst  UNK-1  UNK-4  UNK-S)) 

(send  CNCE-2  set-Unks  (Hat  UNK-1  UNK-2)) 

(send  CNCE-3  set-Unks  (iiat  UNK-2  UNK-3  UNK-5)) 

(send  CNCE-4  ast-Unks  (iiat  UNK-^  UNK-4)) 

(send  UNK-1  aet-ChannalS  (Hat  CHANNEL-11  CHANNEL-12  CHANNEL-13  CHANNEL-14}) 
(send  UNK-2  set-CharmsIs  (iist  CHANNEL-21  CHANNEL-22  CHANNEL-23  CHANNEL-24)) 
(send  UNK-3  set-Chennaia  (list  CHANNEL-31  CHANNEL-32  CHANNEL-33  CHANNEL-34)) 
(send  UNK-4  aet-ChanneiS  (list  CHANNEL^I  CHANNEL42  CHANNEL43  CHANNEL-44)) 
(send  UNK-6  aet-Channels  (list  CHANNEL-51)) 

(send  CHANNEL-11  aet-drcuit  clrcuit-1) 

(send  CHANNEL-21  set-circuit  circuit-1) 

(send  CHANNEL-31  set-circuit  circuit-2) 


^****« 


END 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 


DATE:  27  October  1968 
VERSION:  1.0 

TITLE:  Star  shaped  rietworfc  fle 
RLENAME:  8tar.8 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Ver  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CBptG.R.Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 
COMMANDS:  none 
TOOLS:  none 
UTILITIES:  none 
SYS/MACRO:  none 
NETWORK:  star 

CALLED  BY:  User 
CALLS:  none 

INPUTS:  none 
OUTPUTS:  Network  objects 

VARIABLES  USED:  ‘Clrcult-ID*.  Population 
VARIABLES  CHANGED:  Population 
RLES  READ;  none 
RLES  WRITTEN:  none 


FUNCTION: 

This  block  Of  code  contains  the  commands  to  create  a  network  of 
flee  nodee,  ies  Inks,  20  charvNls  ar«J  no  circuits.  It  looks  like: 

CNCE-1 

Dolno  nodes  before  L<3  f\L-\  Use  the  message 

Nnka,  Inks  be*'  CNCE-6— /-\— CN^-2  message  send  format  to 

channels,  channels  L-2'  <  >1.-4  back  connect  previous 

before  dreute.  /  V  \  objects. 

L-«//\\ 

CNCE-4  CNCE-3 


(setcv  NODE  Population  0)  ;Reoot  upon  loadktg 
(define  *aRCUIT-ID*0) 

(define  CNCE-1 


(make-instance  NODE 

’Name‘CNCE-1)) 

(define  CNCE-2 
(make-instance  NODE 

‘Name ‘CNCE-2)) 

(define  CNCE-3 
(make-instance  NODE 

‘Name 'CNCE-3)) 

(define  CNCE-4 
(make-instance  NODE 

‘Name ’CNCE-4)) 

(define  CNCE-S 
(make-instance  NODE 

’Name'CNCE-S)) 

(define  UNK-l 
(make-instance  UNK 
'Name  'UNK-i 

'Nodes  (iist  CNCE-1  CNCE-3))) 
(define  UNK-2 
(make-instance  UNK 
'Name  'UNK-2 

'Nodes  (iist  CNCE-3  CNCE-5))) 
(define  UNK-3 
(make-instance  UNK 
'Name  ’UNK-3 

'Nodes  (list  CNCE-S  CNCE-2))) 
(define  UNK-4 
(make-instance  UNK 
'Name  'UNK-4 

'Nodes  (list  CNCE-2  CNCE4))) 
(define  UNK-5 
(make-instance  UNK 
'Name 'UNK-5 

'Nodes  Oist  CNCE-4  CNCE-I))) 
(define  CHANNEL-11 
(make-instance  CHANNEL 

'Name 'CHANNEL-11 
'LinkUNK-1)) 

(define  CHANNEL-12 
(make-instance  CHANNEL 

'Name 'CHANNEL-12 
'UnkUNK-1)) 

(define  CHANNEL-13 
(make-instance  CHANNEL 

'Name ’CHANNEL-13 
’UnkUNK-1)) 

(define  CHANNEL-14 
(make-instance  CHANNEL 

'Name ’CHANNEL-14 
’UnkUNK-1)) 

(define  CHANNEL-21 
(make4nstance  CHANNEL 
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'Nanrw 'CHANNEL-21 
‘LinkUNK-2)) 

(define  CHANNEL-22 
(maKe-inetance  CHANNEL 

‘Name 'CHANNEL-22 
’LMcUNK-2)) 

(define  CHANNEL-23 
(make-insiBnce  CHANNEL 

'Name ’CHANNEL-23 
’IJni(UNK-2)) 

(define  CHANNEL-24 
(make-instance  CHANNEL 

'Name  ’CHANNEL-24 
’LinkUNK-2)) 

(d^ine  CHANNEL-31 
(make-instance  CHANNEL 

'Name ’CHANNEL-31 
'LinkUNK-3)) 

(define  CHANNEL-32 
(make-instance  CHANNEL 

'Name 'CHANNEL-32 
'Link  UNK-3)) 

(define  CHANNEL-33 
(make-instance  CHANNEL 

'Name  ‘CHANNEL-33 
‘Link  UNK-3)) 

(define  CHANNEL-34 
(make-instance  CHANNEL 

'Name  'CHANNEL-34 
'Link  UNK-3)) 

(define  CHANNEL-41 
(make-instance  CHANNEL 

'Name  ’CHANNEL-41 
’LinkUNK-4)) 

(define  CHANNEL-42 
(make-instance  CHANNEL 

'Name  'CHANNEL-42 
lJnkUNK-4)) 

(define  CHANNEL-43 
(make-instance  CHANNEL 

'Name ’CHANNEL-43 
’UnkUNK-4)) 

(define  CHANNEL-44 
(make-instance  CHANNEL 

‘Name ’CHANNEL-44 
'LinkUNK-4)) 

(define  CHANNEL-51 
(make4nstance  CHANNEL 

'Name  'CHANNEL-SI 
'LM(UNK-5)) 

(define  CHANNEL-S2 
(make-instance  CHANNEL 


’Name  ’CHANNEL-52 
’UnkUNK-S)) 

(define  CHANNEL-63 
(make-instance  CHANNEL 

’Name  ’CHANNEL-S3 
’LInkUNK-5)) 

(define  CHANNEL-54 
(make-instance  CHANNEL 

’Name ’CHANNEL-54  -  > 

’UnkUNK-S)) 

(send  CNCE-1  set-Unks  (Ust  UNK-1  UNK-5)) 

(send  CNCE-2  set-Links  OW  UNK-3  UNK-4)) 

(send  CNCE-3  set-Links  Oiet  UNK-1  UNK-2)) 

(send  CNCE-4  set-Unks  (list  UNK-4  UNK-5)) 

(send  CNCE-5  set-Unks  (list  UNK-2  UNK-3)) 

(send  UNK-1  set-Channels  (iist  CHANNEL-1 1  CHANNEL-12  CHANNEL-13  CHANNEL-14)) 
(send  UNK-2  set-Channels  (iist  CHANNEL-21  CH/WNEL-22  CHANNEL-23  CHANNEL-24)) 
(send  UNK-3  set-Channeis  (iist  CHANNEL-31  CHANNEL-32  CHANNEL-33  CHANNEL-34)) 
(send  UNK-4  set-Channels  Oist  CHANNEL-41  CHANNEL42  CHANNEL-43  CHANNEL-44)) 
(send  UNK-5  set-Channeis  (iist  CHANNEL-SI  CHANNEL-52  CHANNEL-53  CHANNEL-54)) 
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PROTOTYPE  ROUTE  PLANNER  FOR  ZENITH  248 

DATE:  24  August  1988 
VERSION:  1.0 

TITLE:  Single  path  network  fie 
RLENAME:  stidcs 

OPER  SYS:  DOS  VERSION  3.2 

LANGUAGE:  PC  Scheme  (Var  3.0  Student  Edition)  w/SCOOPS 
AUTHOR:  CaptG.R.Gier 

CONTENTS 
CLASSES:  none 
METHODS:  none 

COMMANDS:  none  -  * 

TOOLS:  none 
UnuTIES:  none 
SYS/MACRO:  none 
NETWORK:  stick 

CALLED  BY:  User 
CALLS;  none 

INPUTS:  none 
OUTPUTS:  Network  objects 

VARIABLES  USED:  *Circuit-ID*,  Population 
VARIABLES  CHANGED:  Population 
FILES  READ;  none 
RLES  WRITTEN:  none 


FUNCTION: 

This  simple  network  works  well  when  debugging  new  code  as  it  has  few 
components,  yet  contains  ail  object  classes  mcept  circuits. 

CNCE-1 - CNCE-2 - CNCE-3 

L-1  L-2 

(Ch-1)  (Ch.2) 

Notice  that  fewer  messages  can  be  sent  If  subsequent  definitions  contain 
Instance  variables  set  to  previously  defined  objects.  Messages  serve  to 
back-connect  those  objects  that  do  not  exist  at  the  time  of  Instantiation. 


(setcv  NODE  Population  0)  ;Reset  node  populadon 
(define  *Circuit-IO*  0) 
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(d6AneCNCE-1  '  * 

(make-instance  NODE 

’Name'CNCE-1)) 

(define  CNCE-2 
(make-instance  NODE 

'Name*CNCE-2)) 

(define  CNCE-3 
(make-instance  NODE 

’Name'CNCE-a)) 

(define  UNK-1 
(make-instance  UNK 
'Name  'UNK-1 

'Nodes  Oist  CNCE-1  CNCE-2))) 
(define  UNK-2 
(make-instance  UNK 
'Name 'UNK-2 

'Nodes  (list  CNCE-2  CNCE-3))) 
(define  CHANNEL-1 
(make-instance  CHANNEL 
'Name  'CHANNEL-1 
'Link  UNK-1)) 

(define  CHANNEL-2 

(make-instance  CHANNEL  *  • 

'Name  'CHANNEL-2 
'Link  UNK-2)) 

(send  CNCE-1  set-Unks  (list  UNK-1)) 

(send  CNCE-2  set-Unks  (list  UNK-1  UNK-2)) 
(send  CNCE-3  set-Unks  (list  UNK-2)) 

(send  UNK-1  set-Channels  (list  CHANNEL-1)) 
(send  UNK-2  set-Channels  (list  CHANNEL-2)) 
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